CONTRACT CHANGE NOTICE - · PDF fileENTERPRISE PROCUREMENT Department of Technology,...

STATE OF MICHIGANENTERPRISE PROCUREMENTDepartment of Technology, Management, and Budget525 W. ALLEGAN ST., LANSING, MICHIGAN 48913P.O. BOX 30026 LANSING, MICHIGAN 48909

CONTRACT CHANGE NOTICE

Change Notice Number 18

to071B4300022Contract Number

$12,223,812.00

January 1, 2014 December 31, 2019

ENTERPRISE SUPPORT SERVICES MIRS RPS ARS

December 31, 2019

INITIAL AVAILABLE OPTIONS EXPIRATION DATE BEFORECHANGE(S) NOTED BELOW

3 - 1 Year

PAYMENT TERMS DELIVERY TIMEFRAME

ALTERNATE PAYMENT OPTIONS EXTENDED PURCHASING

☐ P-Card ☐ Direct Voucher (DV) ☐ Other ☐ Yes ☒ NoMINIMUM DELIVERY REQUIREMENTS

DESCRIPTION OF CHANGE NOTICE

OPTION LENGTH OF OPTION EXTENSION LENGTH OF EXTENSION REVISED EXP. DATE

☐ N/A ☐ N/A December 31, 2019

CURRENT VALUE VALUE OF CHANGE NOTICE ESTIMATED AGGREGATE CONTRACT VALUE

N/A

$44,000.00 $12,267,812.00

Effective 2/20/2018 the attached Statement of Work (SOW) document for the Concealed Pistol License Registry (CPLR ) toMICARS Interface Enhancements are incorporated in this Contract and is increased by $ 44,000.00. All other terms,conditions, specifications, and pricing remain the same. Per agency request and DTMB Procurement approval.

[email protected]

David Gabler

Malu Natarajan

[email protected]

John Leigh

Lathrup village, MI 48076

KUNZ LEIGH & ASSOCIATES INC

*******1652

517-202-4625

28081 Southfield Road

(517) 284-7030

STATE

Pro

gra

m

Manager

Contra

ct

Adm

inistra

tor

CO

NTRACTO

R

MULTI

517-284-4512

INITIAL EXPIRATION DATEINITIAL EFFECTIVE DATE

DTMB

N/A

DESCRIPTION

[email protected]

CONTRACT SUMMARY

CHANGE NOTICE NO. 18 TO CONTRACT NO. 071B4300022

AGENCY NAME PHONE EMAIL

Multi-Agency and Statewide Contracts

Program Managers

for

DTMB Susan Nordyke 517-373-9784 [email protected]

DTMB Annermarie Kelly (517) 241-1243 [email protected]

Kunz, Leigh & Associates P.O. Box 760187 28081 Southfield Road Lathrup Village, MI 48076-0187 Phone: (248) 559-7910 Fax: (248) 559-8066 kunzleigh.com

1 | P a g e

Cover Letter Michigan State Police Attn: Brenda Reynolds Headquarters 7150 Harris Drive Dimondale, MI 48821

Re: CPLR Online Payment Interface to MiCaRS Statement of Work

Dear Ms. Reynolds,

Kunz, Leigh and Associates (KL&A) is pleased to propose application development services to design, develop, test, and deploy a new interface between MiCaRS and CPLR Online Payment that will automate the process of refunding to the counties their portions of concealed pistol license application and renewal fees paid online through the State’s credit card processing function, CEPAS. This interface will allow MiCaRS to consume the credit card payment information from CEPAS, communicate payment information to CPLR, automatically generate the appropriate refunds to the counties, alert the counties by email when revenue allocation has occurred, and produce a revenue-sharing-by-county report.

KL&A proposes a 71-day schedule that will run concurrently with MiCaRS release 3 development. This work will begin April 2018, contingent upon a purchase order being in place. To accomplish this timeline, KL&A intends to allocate to the project a team consisting of a project manager, business analyst, and developer. The total cost for the project will be $44,000.

The attached proposal details the project objectives, scope of work, deliverables, schedule, acceptance criteria, fixed-price cost, payment schedule and assumptions.

If you have any questions, please contact John Leigh at 517-202-4625.

Sincerely,

John Leigh KL&A Partner

CPLR Online Payment Interface to MiCaRS

Statement of Work

Prepared for:

Michigan State Police Constitution Hall

525 W. Allegan St. Lansing, MI 48909

Prepared by:

Kunz, Leigh & Associates 28081 Southfield Road

Lathrup Village, MI 48076-2816

v1.0 December 11, 2017

©2017 Kunz, Leigh & Associates 5

Proposal Signatures Name/Title Signature Date

John K. Leigh, KL&A Partner

12/11/2017


6 v1.0 KL&A

Page intentionally left blank to support duplex printing.

KL&A v1.0 7

Table of Contents 1.0 Project Identification ....................................................................................................................... 9 2.0 Background ...................................................................................................................................... 9 3.0 Project Objective .............................................................................................................................. 9 4.0 Scope of Work .................................................................................................................................. 9

4.1 MiCaRS Modifications ............................................................................................................. 10 4.2 Revenue Web Service .............................................................................................................. 12

4.2.1 Get Revenue .................................................................................................................... 12 4.2.1.1 URL: ...................................................................................................................... 12 4.2.1.2 Query Criteria: ..................................................................................................... 12 4.2.1.3 Web Service Rules:............................................................................................... 12 4.2.1.4 Data Models: ........................................................................................................ 12

4.2.1.4.1 Receipt Model: .............................................................................................. 13 4.2.1.4.2 Remit Model: ................................................................................................. 13 4.2.1.4.3 Document Model .......................................................................................... 14

5.0 Deliverables ................................................................................................................................... 25 6.0 Schedule ......................................................................................................................................... 25 7.0 Acceptance Criteria ........................................................................................................................ 25 8.0 Cost ................................................................................................................................................ 26 9.0 Payment Schedule ......................................................................................................................... 26 10.0 Assumptions .............................................................................................................................. 27

List of Tables Table 1. Deliverables ............................................................................................................................ 25 Table 2. Cost Breakdown ...................................................................................................................... 26 Table 3. Payment Schedule .................................................................................................................. 27 Table 4. Project Assumptions ............................................................................................................... 27


8 v1.0 KL&A


KL&A v1.0 9

1.0 Project Identification Effective December 11, 2017, the Parties agree that all work to be performed will be pursuant to the Statement of Work and to the terms of the Kunz, Leigh & Associates (“Contractor”) Contract 071B4300022. Any changes to the scope of Services described herein shall be pursuant to a modification to this Contract Amendment.

The services described herein (“Services”) and deliverables identified below (“Deliverables”) shall be delivered on a fixed price basis, which means a predefined project model where the Contractor provides the Services, including any Deliverables, for a set fee. Payment will be made upon completion of the Milestone for which the State has received all Services and Deliverables within that Milestone. No partial payment will be accepted.

2.0 Background Concealed Pistol License Registry (CPLR) is required to allow online payments by December of 2018. Registrants will be able to continue to pay for their applications and renewals at their local office or pay for their renewals online. Money received via online payments will be deposited directly to the State of Michigan.

Currently, CPLR sends a list of registrants that have renewed their permits in the local county office to MiCaRS. MiCaRS sends a billing to each county to receive the State’s portion of the fee. Online payments that have already been received by the State will need to be shared with the local county office.

3.0 Project Objective The CPLR online payment process requires these functions:

• Allow online payments though the State’s Credit Card processing system, CEPAS

• Allow CPLR to retrieve daily records of online payments from MiCaRS, via a web service call (a web service is a service offered by an electronic device to another electronic device, communicating with each other via a network)

• Generate a monthly refund to each county for the monies collected online

4.0 Scope of Work The scope of work for these enhancements include:

1. Set up the online payment site through the State’s Credit Card processing system, CEPAS.

2. Facilitate with treasury to receive the daily payment log file from CEPAS to create the deposit information for MiCaRS.


10 v1.0 KL&A

3. Consume the CEPAS transactions into MiCaRS to be sent to SIGMA.

o Table maintenance function to allow MiCaRS user to set up the accounting for the county portion and the state portion of the license fee.

o Create a daily batch of online payments into MiCaRS, using the two accounts for CPLR.

o Use the CPLR Number from the CEPAS log file to determine the county that manages a given license.

4. Set up the Revenue Control web service at MSP to allow the receipt records for the online payments to be pulled into CPLR application.

5. Create a revenue allocation process to create a refund that will return a portion of the online payments back to the county.

o Do not send revenue allocation to any county/ORI that is delinquent on the billing from the State for CPLR.

o Create an auto-approved refund for each non-delinquent ORI based on the account coding designated to be shared.

o Flag the revenue record with the date that the refund was created.

6. Create a report of the revenue transactions that were included in the revenue allocation to each county.

7. Notify each county when the revenue allocation has occurred. Include the report of revenue transactions included in the refund as an attachment to the email.

8. Create a scheduled process to execute the revenue allocation process, generate the report and send the email to each county.

4.1 Approach MiCaRS is currently in maintenance and support, as such has a set release schedule for fiscal year 2018. When new work is proposed, such as the work detail in this statement of work (SOW), the work must be slotted for one or more of the scheduled releases. Each release is essentially a short project. A release is comprised of an initiation and planning period, 3 to 4 2-week development sprints, system testing, user acceptance testing, and a production cut-over period.

The estimated work to complete the proposed CPLR Online Payment Interface enhancements will fit into a single scheduled release. To ensure that regular maintenance and support activities are not impacted by the proposed work additional resources will be added to the MiCaRS team in the form of a developer, part-time business analyst, and part-time project manager.

The KL&A team will work with the MSP during initiation and planning to validate the modifications provided in this SOW. Once validation is complete, work will be prioritized and completed as part of

Scope of Work

KL&A v1.0 11

the standard Scrum ceremonies: backlog grooming, sprint planning, sprint construction and testing, sprint review, and system testing (ST).

The release includes a user acceptance testing (UAT) phase which begins when the development sprints are complete. UAT is 20 business days in duration and includes a test plan, test cases and test result reporting. The execution of test cases is the responsibility of MSP during the prescribed UAT phase.

The production cut-over phase of the release is 15 business days in duration with execution coming by way of SOM and KL&A resources. As code is migrated from development to staging the transition process is tested and refined producing a productive and smooth cut-over to production.

4.2 MiCaRS Modifications Create a CPLR Revenue Split Maintenance screen to allow a MiCaRS user to identify the Hot Keys to be used for the CPLR interface and how to split the payment between the hot keys.

Facilitate with Treasury to have the new log file from the CPLR CEPAS Pay Point Site sent to the MSP CEPAS mailbox on the FTS.

Create a CEPAS Processing procedure to:

• Create a Revenue Batch for the CPLR CEPAS transactions. This process will create document records for each payment based on the configured revenue split information.

• Store the county code that will be part of the reference data in the CEPAS log file in the Interface ID for the Hot Key that represents the county’s share. This will be determined using a dblink view to the CPLR database.

Create a revenue allocation process to return the money that has been paid through CEPAS, which involves:

• Identifying ORIs that have a delinquent CPLR Invoice (older than one month) to prevent a revenue allocation request being sent to a county that is not sending their required payments to the State.

• Creating an auto-approved refund record on a monthly basis for non-delinquent ORIs.

• Issuing the refund for the ORI that is associated with the county.

• Configure the CPLR hot keys to allow manual entry of revenue into MiCaRS. This will support entry and validation of the CPLR number and county.

• Produce a report of revenue transactions that were included in the revenue allocation to each county. This report will only be generated for the county/ORI that will be receiving a revenue allocation check.


12 v1.0 KL&A

• Revenue allocation will be scheduled using a tool that can invoke a database process and call a web service end-point to generate the report for emailing.

• Modify Cashier Query to search by Interfaced date NULL to be able to locate transactions that are pending revenue. Revenue Web Service

Deploy the Revenue web service to MSP Servers so CPLR can access the URL.

Configure the Revenue Authentication for CPLR so the application will be able to connect successfully.

4.2.1 Get Revenue A MiCaRS webservice is exposed for external systems to call. The method, GetRevenue, will provide the external system with details for the MiCaRS revenue transaction information that was allocated to a specific Hot Key. This method accepts a GET request.

4.2.1.1 URL:

api/revenue?startingDateToSigma=2016-10-10&endingDateToSigma=2017-03-21&interfaced=false

4.2.1.2 Query Criteria:

a. System Key (unique identifier for the calling system), which needs to be provided in the Authorization Header included on the web request.

b. Interfaced (optional criteria) (Boolean). Transactions that have not previously been sent. These are identified by a blank Interface date on the HistDoc record.

c. Date Range (inclusive criteria, optional criteria, “2016-11-01”) . Transactions that have been sent to SIGMA. These are indentifed by the date to sigma on the HistDoc record.

• startingDateToSigma

• endingDateToSigma

4.2.1.3 Web Service Rules:

a. Check Amount <> $0

b. At least one document was allocated to the system key or interface invoice exists in MiCaRS

4.2.1.4 Data Models: The revenue information returned from GetRevenue will be in dataset form and contain all of the elements below.

Scope of Work

KL&A v1.0 13

4.2.1.4.1 Receipt Model:

Column Name

Data Type Req. Source Description

ControlNumber

Number(12) R HistRec. Control_Number

Unique record identifier

ReceiptDate Date R HistRec. Receipt_Date

Name on check, not necessarily the provider.

Documents List<DocumentModel>

R List of detailed accounting for the revenue transaction

Remit List<RemitModel> R List the remittance details for the revenue transaction

4.2.1.4.2 Remit Model:

Column Name

Data Type Req. Source Description

EntryNumber Number R HistRem. Enrty_Number

Indentifies the record within the control number

CheckNumber

String(15) HistRem. Check_Number

Check number, only required for certain remit types

RemitReference

String(20) HistRem.Remit_Reference

A user defined field to enter information pertinent to the remit

RemitType String(2) R HistRem.Remit_Type

Code that identifies the type of payment

RemitAmount Number(12,2) R HistRem. Remit_Amount

The full amount of the check

RemitName String(30) R HistRem.Remit_Name

Name of the person or organization responsible for the report


14 v1.0 KL&A

4.2.1.4.3 Document Model

Column Name Data Type Req. Source Description

MiCaRS Entry Number

Number(4) R HistDoc. Entry_Number

Number that identifies the document within each control number. Sequential number assigned by the system.

HotKey String(10) O HistDoc. Hot_Key

DocumentAmount

NUMBER(12,2) R HistDoc. Document Amount

Amount that is currently allocated to this accounting

Fund String(4) CR HistDoc.Fund SIGMA identification code associated with the fund. The Fund code must be provided if the Accounting Template is blank OR the provided Accounting Template is not set with a Fund code in SIGMA. If provided, must be valid on Fund (FUND) table.

SubFund String(4) O HistDoc.Sub_Fund SIGMA identification code associated with the sub-fund.

Scope of Work

KL&A v1.0 15


Object String(4) CR HistDoc.Object SIGMA identification code associated with an object of expenditure. For expenditure based transactions, the Object code must be provided if the Accounting Template is blank, the provided Accounting Template is not set with an Object code in SIGMA, the Department Object is blank OR the provided Department Object is not associated with an Object code on the Object Inference table in SIGMA. The field is prohibited when a revenue refund and when a balance sheet payment. If provided, must be valid on the Object table.

Revenue String2(4) CR HistDoc.Revenue Revenue sources are used to track


16 v1.0 KL&A


individual sources of revenue taken in. For revenue based transactions, the Revenue Source code must be provided if the Accounting Template is blank, the provided Accounting Template is not set with a Revenue Source code in SIGMA, the Department Revenue Source is blank OR the provided Department Revenue Source is not associated with a Revenue Source code on the Revenue Source Inference table in SIGMA. The field is prohibited for all other transactions. If provided, must be valid on the Revenue table

Department String(4) CR HistDoc.Department SIGMA identification code

Scope of Work

KL&A v1.0 17


associated with a department. The Department must be provided for revenue and expenditure transactions if the Accounting Template is blank OR the provided Accounting Template is not set with a Department code in SIGMA. If provided, it must be valid on Department Fiscal Year Controls table

Unit String(4) CR HistDoc.Unit SIGMA identification code associated with a unit. The Unit must be provided for revenue and expenditure transactions if the Accounting Template is blank OR the provided Accounting Template is not set with a Unit code in SIGMA.


18 v1.0 KL&A


Must be valid on the Unit table if provided

SubUnit String(4) O HistDoc.Sub_Unit Sub Unit is a means of breaking down a unit code into smaller measurements. It is the lowest level of organizational structure and is required or prohibited based on one or more sub unit requirement tables. To enter a Sub Unit Code, the Unit Code must be entered.

AppropriationUnit

String(9) CR HistDoc.Appropriation_Unit

SIGMA identification code associated with an appropriation unit. The Appropriation Unit must be provided if the Accounting Template is blank OR the provided Accounting Template is not set with an Appropriation Unit in SIGMA.

Scope of Work

KL&A v1.0 19


If provided, must be valid on the Appropriation table.

Bsa String (4) CR HistDoc.Bsa SIGMA identification code assigned to the balance sheet account. This field is required if recording balance sheet activity and the Accounting Template is blank OR the provided Accounting Template is not set with a BSA in SIGMA. The field is prohibited for all other transactions. If provided, it must be valid on the BSA table in SIGMA.

SubBsa String(4) O HistDoc.Sub_Bsa SIGMA identification code assigned to the sub-balance sheet account. If provided, must be valid on the Sub BSA table.


20 v1.0 KL&A


To enter a Sub BSA Code, the BSA Code must be entered.

Department Object

String(4) O HistDoc.Department_Object

SIGMA identification code assigned to the Department object. If provided, must be valid on the Department Object table.

Department Revenue

String(4) O HistDoc.Department_Revenue

SIGMA code assigned to the department revenue source. If provided, must be valid on the Department Revenue Source table.

Location String(4) O HistDoc.Location SIGMA identification code assigned to the location. If provided, must be valid on the Location table.

SubLocation String(4) O HistDoc.Sub_Location SIGMA identification code associated with the sub-location.

Scope of Work

KL&A v1.0 21


If provided, must be valid on the Sub Location table. To enter a Sub Location Code, the Location Code must be entered.

Activity String (4) O HistDoc.Activity SIGMA identification code associated with the activity. If provided, must be valid on the Activity table

SubActivity String(4) O HistDoc.Sub_Activity SIGMA identification code associated with the sub-activity. If provided, must be valid on the Sub Activity table. To enter a Sub Activity Code, the Activity Code must be entered.

Function String(10) O HistDoc.Function SIGMA identification code associated with the function. The function code defines broad operational objectives, such as instruction,


22 v1.0 KL&A


support services, and facilities acquisition. If provided, must be valid on the Function table.

SubFunction String(4) O HistDoc.Sub_Function SIGMA identification code associated with the sub-function. If provided, must be valid on the Sub Function table. To enter a Sub Function Code, the Function Code must be entered.

Reporting String(10) O HistDoc.Reporting The reporting code element is used for tracking contract activity. The contract number will be entered in this field. If provided, must be valid on the Reporting Code table.

SubReporting String(4) O HistDoc.Sub_Reporting Sub reporting codes define contract periods.

Scope of Work

KL&A v1.0 23


If provided, must be valid on the Sub Reporting table. To enter a Sub Reporting Code, the Reporting Code must be entered.

Task String(4) O HistDoc.Task The unique identification code assigned to the task. If provided, must be valid on the Task table.

SubTask String(4) O HistDoc.Sub_Task The sub task is a means of breaking down tasks into smaller components. If provided must be valid on Sub Task table. To enter a Sub Task Code, the Task Code must be entered.

Task String(4) O HistDoc.Task The unique identification code assigned to the task.


24 v1.0 KL&A


If provided, must be valid on the Task.

InvoiceNumber Number(12,2) O HistDoc.Invoice_Number Unique number which identifies an invoice.

DepositDate Date O HistDoc.Deposit_Date Generic reference ID field for interfacing

DepositNmber String(8) O HistDoc.Deposit_Number The bank deposit ticket number assigned to the deposit transaction

DepositSuffix String(3) O HistDoc.Deposit_Suffix A three-digit code assigned to allow more detail break out of transactions.

CustomerName

String(60) O HistDoc.Customer_Name Customer last name, first name and middle name strung together with no spaces.

Comments String(50) O Histdoc.Comments Internal comments on the transaction.

InterfaceId1 String50) O HistDoc. Interface_ID1

CPLR Number sent to CEPAS request by CPLR.

Interface_ID2 STRING2(50) O HistDoc. Interface_ID2

County code determined by MiCaRS based on the CPLR number.

Schedule

KL&A v1.0 25


Interface_ID3 String2(50) O HistDoc.Doc. Interface_ID3

Generic reference ID field for interfacing.

Interface_ID4 String2(50) O HistDoc.Doc. Interface_ID4

Generic reference ID field for interfacing.

5.0 Deliverables This Statement of Work includes the deliverables listed in the table below.

Table 1. Deliverables

Deliverable Project Charter

Project Schedule Application Code

Test Plan Installation Plan

Production Cut-over

6.0 Schedule The work for this statement of work will be completed as part of MiCaRS FY18 Release 3 if a purchase order is in place.

**The start date for development is not finalized. The plan is to finalize the development start date no later than mid-February 2018. Schedule needs to be updated upon finalization.

WBS Task Name Duration Projected Start Projected Finish 1.6.3 MiCaRS Release 3 68 days Mon 4/16/18 Fri 7/20/18

1.6.3.1 Initiation and Planning 5 days Mon 4/16/18 Fri 4/20/18 1.6.3.1.1 Project Charter 5 days Mon 4/16/18 Fri 4/20/18 1.6.3.1.2 Project Schedule 5 days Mon 4/16/18 Fri 4/20/18

1.6.3.1.3 New Work Requirement Validation 5 days Mon 4/16/18 Fri 4/20/18 1.6.3.2 Release 3 Sprints 40 days Mon 4/23/18 Mon 6/18/18 1.6.3.2.1 Sprint 1 10 days Mon 4/23/18 Fri 5/4/18

1.6.3.2.2 Sprint 2 10 days Mon 5/7/18 Fri 5/18/18 1.6.3.2.3 Sprint 3 10 days Mon 5/21/18 Mon 6/4/18 1.6.3.2.4 Sprint 4 10 days Tue 6/5/18 Mon 6/18/18

1.6.3.3 Release 3 UAT 30 days Tue 6/5/18 Tue 7/17/18 1.6.3.3.1 UAT Planning 10 days Tue 6/5/18 Mon 6/18/18


26 v1.0 KL&A

WBS Task Name Duration Projected Start Projected Finish 1.6.3.3.2 UAT Execution 20 days Tue 6/19/18 Tue 7/17/18

1.6.3.4 Release 3 Production Cut-over 23 days Tue 6/19/18 Fri 7/20/18 1.6.3.4.1 Production Cut-over Planning 5 days Tue 6/19/18 Mon 6/25/18 1.6.3.4.2 Implementation Plan 15 days Tue 6/19/18 Tue 7/10/18

1.6.3.4.3 Cut-over Execution 1 day Fri 7/20/18 Fri 7/20/18

7.0 Acceptance Criteria Production cut-over constitutes acceptance of this scope of work and deliverables.

8.0 Cost This is a fixed-price proposal. Pricing includes cost for a developer, a business analyst and a project manager.

Table 2. Cost Breakdown

Task Hours Cost MiCaRS Modifications – Development 150 $13,500 MiCaRS Modifications – Support and Testing 72 $7,200 Revenue Web Service – Development 40 $3,600 Revenue Web Service – Support and Testing 20 $2,000 CEPAS Processing – Development 50 $4,500 CEPAS Processing – Support and Testing 32 $3,200

Project Management 80 $10,000 Total 444 $44,000

9.0 The fiscal year 2018 maintenance and support cost for the interface between CPLR and MiCaRS is $2,000. The maintenance and support cost for the interface between CPLR and MiCaRS will

Assumptions

KL&A v1.0 27

be $5,000 beginning fiscal year 2019.Payment Schedule

Table 3. Payment Schedule

Milestone Deliverables Relating to Milestone

Acceptance Criteria Payment

Initiation, Planning and Development

Project Charter Project Schedule

Development Sprints

Completion of initiation and planning deliverables,

and completion of development sprints.

$26,600

Testing and Production Cut-over

Updated Code Test Cases Test Plan

Installation Plan

Completion of deliverables and production cut-over.

$17,400

10.0 Assumptions Table 4. Project Assumptions

Project Assumptions

A project start date will be set upon receipt of a purchase order. KL&A observes the following non-working holidays: • Memorial Day • July 4th (or the Friday or Monday closest to the 4th) • Labor Day • Thanksgiving and the Friday after Thanksgiving • Christmas Eve and Christmas Day • New Year’s Eve and New Year’s Day

All other non-weekend calendar days, and non-State holidays, are treated as workdays, with the assumption that both KL&A and MSP stakeholders are available to complete project-related tasks. This proposal is a fixed-price bid. Change requests approved by MSP and DTMB may affect the price and schedule as defined within the Request of Change. KL&A will provide test cases and test plans for User Acceptance Testing (UAT) and will facilitate UAT. UAT test cases will be written and executed using Jama, which provides traceability. Issues found during testing will be recorded in JIRA, KL&A’s web-based issue tracking tool. Any failures reported during UAT that KL&A deems outside the scope of this project may be handled through a “change request” process.


28 v1.0 KL&A

Project Assumptions

DTMB will be responsible for deploying releases to production. KL&A will initiate the release process via an RFC. KL&A will be responsible for deploying releases to the development database and web servers. CPLR will be responsible for consuming web services. MSP Finance will work with Treasury to get the CEPAS Pay Point Merchant and Application ID set up and record that information in the MiCaRS CEPAS Configuration table. The CPLR Online Renewal application will interact directly with CEPAS Pay Point via a redirect to the CEPAS Pay Point Web Site. The CPLR Online renewal application will include the CPLR Application ID and the County ID in the call to the CEPAS Pay Point site so that the CEPAS log file will contain the CPLR number and county ID in the reference data separated by a dash.

11.0 Roles and Responsibilities The table below outlines the roles and responsibilities needed to complete the work outlined in this statement of work.

Table 5. Roles and Responsibilities

Role Responsibility MSP Sponsor The MSP Sponsor represents the business executive leadership for the

project. The MSP Sponsor will coordinate with the DTMB Sponsor to: • Resolve escalated project issues in a timely manner • Review project management plan, schedule, status, and issues • Resolve escalated deviations from project management plan or

schedule • Provide change control review and approval • Ensure timely availability of escalated State resource issues

DTMB Sponsor The DTMB Sponsor represents the technology executive leadership for the project. The DTMB Sponsor will coordinate with the MSP Sponsor to: • Resolve escalated project issues in a timely manner • Review project management plan, schedule, status, and issues • Resolve escalated deviations from project management plan or

schedule • Provide change control review and approval • Ensure timely availability of escalated State resource issues

Roles and Responsibilities

KL&A v1.0 29

Role Responsibility MiCaRS Product Owner • Primary point of contact for all business-related discussions

• Coordinate SME resources for JAD, planning / standup / demo activities

• Perform duties as necessary for Steering Committee, Change Control Board, and Project Leadership

• Perform project documentation and deliverable review and approval

• Monitor timelines and scope for early containment of extensions and expansion

• Coordinate and/or execute user acceptance testing Subject Matter Experts (SMEs)

• A SNC Subject Matter Expert is an individual who has expert knowledge of a business subject or requirement and is able to answer questions brought forward

• Assist with new solution design, document review, and testing efforts

DTMB Project Manager • Obtain the relevant DTMB, DNR, and/or State department/division concurrence(s) for any Contractor requested change or standard deviation to this contract.

• Provide State facilities, as needed • Coordinate the DTMB resources necessary for the project • Facilitate coordination between various external contractors • Facilitate communication between different State

departments/divisions • Provide acceptance and sign-off of deliverable/milestone • Review and sign-off of timesheets and invoices • Resolve project issues • Escalate outstanding/high priority issues • Utilize change control procedures • Conduct regular and ongoing review of the project to confirm that

it meets original objectives and requirements • Document and archive all important project decisions • Arrange, schedule and facilitate State staff attendance at all project

meetings DTMB Database Administrator

• Run database release scripts in the existing MiCaRS test and production environments

DTMB Web Administrator

• Move MiCaRS code deployment to existing test and production environments.


30 v1.0 KL&A

Role Responsibility KL&A Project Manager • Manage all defined Contractor responsibilities in the Scope of

Services • Manage identified subcontractors • Develop the project management plan and schedule, updating as

needed • Serve as the point person for all project issues • Coordinate and oversee the day-to-day project activities of the

project team • Assess and report project feedback and status • Escalate project issues, project risks, and other concerns • Review all project deliverables and provide feedback

KL&A Business Analyst • Eliciting functional and technical requirements • Performing gap analysis • Documenting use case scenarios • Performing business and workflow analysis • Decomposing business and functional requirements into user

stories • Facilitating meetings • Writing test cases and test plans • Creating user guides and other training materials

KL&A Developer • Developing and implementing the new application • Conducting unit testing • Performing code reviews





$12,120,637.00



December 31, 2019

INITIAL AVAILABLE OPTIONS EXPIRATION DATE BEFORE CHANGE(S) NOTED BELOW

3 - 1 Year




DESCRIPTION OF CHANGE NOTICEOPTION LENGTH OF OPTION EXTENSION LENGTH OF EXTENSION REVISED EXP. DATE

☐ ☐ December 31, 2019


N/A

$103,175.00 $12,223,812.00

Effective February 6, 2018, the attached Statement of Work (SOW) document for Newborn Screening Online Invoicing & Enhancement is incorporated into this Contract and is increased by $103,175.00. All other terms, conditions, specifications, and pricing remain the same. Per agency request and DTMB Procurement agreement and State Ad Ministrative approval on 2/6/2018.

[email protected]

David Gabler

Malu Natarajan

[email protected]

John Leigh



*******1652

517-202-4625


(517) 284-7030

STATE

Pro

gra

m

Manager

Contra

ct

Adm

inistra

tor

CO

NTRA

CTO

R

MULTI

517-284-4512


DTMB

N/A

DESCRIPTION

[email protected]

CONTRACT SUMMARY




Program Managers

for



STATE OF MICHIGAN ENTERPRISE PROCUREMENT Department of Technology, Management, and Budget 525 W. ALLEGAN ST., LANSING, MICHIGAN 48913 P.O. BOX 30026 LANSING, MICHIGAN 48909



to Contract Number 071B4300022

CONTRACT SUMMARY

ENTERPRISE SUPPORT SERVICES MIRS RPS ARS INITIAL EFFECTIVE DATE INITIAL EXPIRATION DATE INITIAL AVAILABLE OPTIONS EXPIRATION DATE BEFORE

CHANGE(S) NOTED BELOW

January 1, 2014 December 31, 2019 3 - 1 Year December 31, 2019


N/A


□ P-Card ☐ Direct Voucher (DV) ☐ Other □ Yes ☒ No MINIMUM DELIVERY REQUIREMENTS

N/A DESCRIPTION OF CHANGE NOTICE


☐ ☐ December 31, 2019


$11,661,938.37 $425,458.63 $12,087,397.00

DESCRIPTION

Effective October 1, 2017, the FY18 Maintenance and Support Statement of Work (SOW) document for $1,023,100.00 is incorporated into this Contract. Of the $1,023,100.00, $597,641.37 is already available on the Contract and therefore the balance amount $425,458.63 is being added to the Contract. All other terms, conditions, specifications, and pricing remain the same per Contractor and Agency agreement, and DTMB approval.

STATE

Pro

gra

m

Manager

David Gabler MULTI

517-284-4512

[email protected] Contra

ct

Adm

inistra

tor

Malu Natarajan DTMB

(517) 284-7030

[email protected]

CO

NTRACTO

R




John Leigh

517-202-4625

[email protected]

*******1652

mailto:[email protected]



KL&A 1

Statement of Work Fiscal Year 2018 Maintenance and Support

2

1.0 Project Identification Effective October 2017, the Parties (State of Michigan and KL&A) agree that all work to be

performed will be pursuant to this Statement of Work and to the terms of the Kunz, Leigh &

Associates (“Contractor”) Contract 071B4300022. Any changes to the scope of Services described

herein shall be pursuant to a modification to this Contract Amendment.

The services described herein (“Services”) and deliverables identified herein (“Deliverables”) shall be

delivered on a fixed‐price basis, which means a predefined project model, where the Contractor

provides the Services, including any Deliverables, for a set fee.

2.0 Background In accordance with State of Michigan (SOM) contract 071B4300022, Kunz, Leigh & Associates (KL&A)

provides maintenance and support services for 3 major applications, as well as many interfaces.

Contract 071B4300022 outlines the services and activities provided in support of the following

applications and all associated application interfaces:

MiCaRS – Web based accounts receivable and revenue processing system (Cashiering) that

interfaces to the State’s accounting system.

RPS/ARS – An accounts receivable and revenue processing system (Cashiering) that interfaces to

the State’s accounting system.

MIRS – A budget management and reporting system that interfaces with MIDB for financial

analysis and budget reporting.

3.0 Project Objective The objective of this Statement of Work (SOW) is to initiate and provide maintenance and support

services for fiscal year 2018.

4.0 Scope of Work KL&A will provide ongoing Level 1 maintenance and support for all applications listed in Section 5.0.

Maintenance and support activities covered under contract 071B4300022 are performed by a

maintenance team. The team is composed of a project manager and one or more developers. Their

responsibilities include supporting users with production issues, performing scheduled maintenance

releases that include defect resolution, and a list of other activities outlined in the contract.

3

The approach discussed above applies to the following applications and all interfaces in fiscal year

2018:

Michigan Cashiering and Receivable System (MiCaRS)

Remittance Processing System (RPS or RPS/ARS)

MIDB Inquiry and Reporting System (MIRS)

Civil Service Assessment Application

STAR Referral System (STAR)

Record Lookup System (RLS)

Request Management System (RMS)

Radiation Safety Data System (RSDS)

RSDS iPad

Health Facilities Engineering System (HFES)

Facilities Maintenance System (FMS)

The State of Michigan SIGMA project is large in scale and complexity. The move from MAIN to

SIGMA required upgrades to MiCaRS, RPS and interfaces to allow interfacing with SIGMA. KL&A’s

experience tells us that projects large in scale and complexity require an increased level of

maintenance and support in the form of stabilization for at least the first year of production use.

Translated, KL&A is proposing an increase in cost for MiCaRS/RPS stabilization for a duration of a full

year to handle the expected increase in support.

4.1 Scope Changes MIRS, at many of the agencies, is at its end of life with the implementation of SIGMA. The MIRS

support fee is reduced by half to cover 6 months of maintenance for this year. After the 6

months is complete, KL&A will no longer provide maintenance and support for MIRS at the

following agencies:

o DARD

o DTMB

o Treasury

Fees are adjusted for the addition of the dedicated MiCaRS maintenance and support team.

DOS – UCC interface is no longer external to RPS. The functionality is now internal to RPS,

resulting in a reduced fee added to the base RPS/ARS fee.

DNR – KL&A completed a new interface from MiCaRS to the Customer Reservation System

(CRS). The result is a new interface fee.

DHHS – EMS is being replaced and will no longer require support from KL&A.

DOT – PAB functionality is moving to SIGMA.

4

DNR – EJV functionality is moving to SIGMA and MiCaRS.

5.0 Project Services and Deliverables This section specifies project services and deliverables, broken out by agency.

5.1 Department of State

KL&A will provide maintenance, support, and the corresponding interfaces for the following

applications within the Department of State as follows:

Application Services and Deliverables Contract Fee

FY 2018 Adjusted Fee

Fee Adjustment Reason

RPS/ARS Continuing maintenance and support $ 25,000.00 $ 70,000.00

Increase due to SIGMA stabilization and support.

Application Interfaces

STAR Referral System $ 5,000.00 $ 10,000.00

Increase due to increase in support.

UCC $ 5,000.00 ‐ Project removed from support.

Record Lookup System $ 20,000.00 $ 25,000.00 Increase due to increase in support.

Credit Card Reader $ 5,000.00 $ 5,000.00

IRP Web Services $ 5,000.00 $ 5,000.00

Request Management System (RMS) $ ‐ $ 10,000.00

New 2015

UCC Web Services $ ‐ $ 5,000.00 New 2016

Total $ 65,000.00 $ 130,000.00

5.2 State Police


applications within the State Police as follows:




MiCaRS Continuing maintenance and support $ 12,000.00 $ 70,000.00



Crash $ 10,000.00 $ 10,000.00

LEIN/VBP $ 10,000.00 $ 10,000.00

SmartScan $ 2,000.00 $ 2,000.00

OffenderWatch $ 5,000.00 $ 5,000.00

CCW/Alias $ 5,000.00 $ 5,000.00

CPLR $ 2,000.00 $ 2,000.00

PPC $ 10,000.00 $ 25,000.00 Increase due to new functionality and complexity.

FOIA $ ‐ $ 12,000.00 New 2015

Total $ 56,000.00 $ 141,000.00

5

5.3 Department Health and Human Services


applications within the Department Health and Human Services as follows:






MIRS Continuing maintenance and support $ 15,000.00 $ ‐ Project removed from support.


TED (PPRS + PCRS) $ 30,000.00 $ 30,000.00

QAA $ 5,000.00 $ 5,000.00

CEPAS $ 12,000.00 $ 12,000.00

CHAMPS $ 7,500.00 $ 7,500.00

DMS $ 5,000.00 $ 5,000.00

EMS $ 5,000.00 $ ‐ Project removed from support.

ASAP $ 10,000.00 $ 10,000.00

NBS $ 20,000.00 New 2015

Total $ 109,500.00 $ 229,500.00

5.4 Department of Natural Resources


applications within the Department of Natural Resources as follows:






EJV $ 5,000.00 $ ‐ Project removed from support.

LOTS $ ‐ $ 8,000.00 New 2016

Customer Reservation System $ ‐ $ 12,000.00 New 2017

Total $ 17,000.00 $ 90,000.00

5.5 Department of Agriculture and Rural Development


applications within the Department of Agriculture and Rural Development as follows:

6




MIRS Continuing maintenance and support $ 20,000.00 $ 10,000.00

Reduced due to end of life March 2018

MiCaRS Continuing maintenance and support $ ‐ $ 70,000.00 New 2014


Accela $ ‐ $ 18,000.00 New 2017

Total $ 20,000.00 $ 98,000.00

5.6 Department of Transportation


applications within the Department of Transportation as follows:







PAB $ ‐ $ ‐ New 2016; Removed 2017

Total $ 12,000.00 $ 70,000.00

5.7 Department of Environmental Quality


applications within the Department of Environmental Quality as follows:






SMILE $ ‐ $ 8,000.00 New 2016

MiWaters $ ‐ $ 8,000.00 New 2016

Labworks Toolkit $ ‐ $ 12,000.00 New 2016

Total $ ‐ $ 98,000.00

5.8 Department of Treasury


applications within the Department of Treasury as follows:

7

Application Services and Deliverables Contract Fee FY 2018 Adjusted Fee






STAR $ ‐ $ 5,000.00 New 2016

Total $ 15,000.00 $ 85,000.00

5.9 Department of Licensing and Regulatory Affairs


applications within the Department of Licensing and Regulatory Affairs as follows:




Radiation Safety $ 15,000.00 $ 15,000.00

RSDS iPad $ ‐ $ 6,600.00 New 2015

HFES $ 32,000.00 $ 15,000.00 Reduced due to decease in needed support.

FMS $ 28,000.00 $ 15,000.00 Reduced due to decease in needed support.

Total $ 75,000.00 $ 51,600.00

5.10 Michigan Civil Service Commission


applications within the Michigan Civil Service Commission as follows:




Total $ 20,000.00 $ 20,000.00

5.11 Department of Technology, Management and

Budget


applications within the Department of Technology, Management and Budget as follows:





8



Total $ 20,000.00 $ 10,000.00

6.0 Project Control and Reports A Progress Report will be provided to the Contract Administrator and designated DTMB recipients

on a quarterly basis. The Contractor will state the tasks completed during the reporting period.

These include, but are not limited to, the following:

1. Reports on any application defects or errors

2. Issues and Resolutions Log Report

3. Recommendations for application changes

4. Change Log Reports

5. Defect Log Reports

6. Quality Management Report

7. Root Cause Analysis Report explaining the root cause of all errors

7.0 Payment Schedule The price for Professional Services is for fixed firm deliverables based on the existing Contract Rate

Card. The total purchase price for this SOW is $1,023,100. This total figure is made up of the items

outline in Sections 4 and 5.

8.0 Schedule The schedule included with this statement of work is subject to changed based on the needs of each

agency and/or project.

WBS Task Name Duration Predecessors Projected

Start Projected

Finish

1 KL&A Fiscal Year 2018 Maintenance and Support Release Schedule

241.13 days

Mon 10/2/17 Thu 9/20/18

1.1 Department of State Release Schedules 241.13

days Mon 10/2/17 Thu 9/20/18

1.1.1 RPS Release Schedule 241.13

days Mon 10/2/17 Thu 9/20/18

1.1.1.1 RPS Warranty Release 63 days Mon 10/2/17 Mon 1/8/18

1.1.1.1.1 Warranty Release Sprints 40 days Mon 10/2/17 Thu 11/30/17

1.1.1.1.1.1 Sprint 1 10 days Mon 10/2/17 Mon 10/16/17

1.1.1.1.1.2 Sprint 2 10 days 6 Mon 10/16/17 Mon 10/30/17

1.1.1.1.1.3 Sprint 3 10 days 7 Mon 10/30/17 Tue 11/14/17

1.1.1.1.1.4 Sprint 4 10 days 8 Tue 11/14/17 Thu 11/30/17

9


Start Projected

Finish

1.1.1.1.2 Warranty Release UAT 30 days Tue 11/14/17 Wed 1/3/18

1.1.1.1.2.1 UAT Planning 10 days 9SS Tue 11/14/17 Thu 11/30/17

1.1.1.1.2.2 UAT Execution 20 days 9 Thu 11/30/17 Wed 1/3/18

1.1.1.1.3 Warranty Release Production Cut-over 23 days Thu 11/30/17 Mon 1/8/18

1.1.1.1.3.1 Production Cut-over Planning 5 days 12SS Thu 11/30/17 Thu 12/7/17

1.1.1.1.3.2 Implementation Plan 15 days 12SS Thu 11/30/17 Thu 12/21/17

1.1.1.1.3.3 Cut-over Execution 1 day 12FS+2 days Fri 1/5/18 Mon 1/8/18

1.1.1.2 RPS Release 2 63 days Tue 1/16/18 Fri 4/13/18

1.1.1.2.1 Release 2 Sprints 40 days Tue 1/16/18 Tue 3/13/18

1.1.1.2.1.1 Sprint 1 10 days Tue 1/16/18 Mon 1/29/18

1.1.1.2.1.2 Sprint 2 10 days 19 Tue 1/30/18 Mon 2/12/18

1.1.1.2.1.3 Sprint 3 10 days 20 Tue 2/13/18 Tue 2/27/18

1.1.1.2.1.4 Sprint 4 10 days 21 Wed 2/28/18 Tue 3/13/18

1.1.1.2.2 Release 2 UAT 30 days Wed 2/28/18 Tue 4/10/18

1.1.1.2.2.1 UAT Planning 10 days 22SS Wed 2/28/18 Tue 3/13/18

1.1.1.2.2.2 UAT Execution 20 days 22 Wed 3/14/18 Tue 4/10/18

1.1.1.2.3 Release 2 Production Cut-over 23 days Wed 3/14/18 Fri 4/13/18

1.1.1.2.3.1 Production Cut-over Planning 5 days 25SS Wed 3/14/18 Tue 3/20/18

1.1.1.2.3.2 Implementation Plan 15 days 25SS Wed 3/14/18 Tue 4/3/18

1.1.1.2.3.3 Cut-over Execution 1 day 25FS+2 days Fri 4/13/18 Fri 4/13/18

1.1.1.3 RPS Release 3 63 days Mon 4/23/18 Fri 7/20/18

1.1.1.3.1 Release 3 Sprints 40 days Mon 4/23/18 Mon 6/18/18

1.1.1.3.1.1 Sprint 1 10 days Mon 4/23/18 Fri 5/4/18

1.1.1.3.1.2 Sprint 2 10 days 32 Mon 5/7/18 Fri 5/18/18



1.1.1.3.2 Release 3 UAT 30 days Tue 6/5/18 Tue 7/17/18

1.1.1.3.2.1 UAT Planning 10 days 35SS Tue 6/5/18 Mon 6/18/18

1.1.1.3.2.2 UAT Execution 20 days 35 Tue 6/19/18 Tue 7/17/18

1.1.1.3.3 Release 3 Production Cut-over 23 days Tue 6/19/18 Fri 7/20/18

1.1.1.3.3.1 Production Cut-over Planning 5 days 38SS Tue 6/19/18 Mon 6/25/18

1.1.1.3.3.2 Implementation Plan 15 days 38SS Tue 6/19/18 Tue 7/10/18


1.1.1.4 RPS Release 4 43 days Mon 7/23/18 Thu 9/20/18

1.1.1.4.1 Release 4 Sprints 20 days Mon 7/23/18 Fri 8/17/18



1.1.1.4.2 Release 4 UAT 30 days Mon 8/6/18 Mon 9/17/18

1.1.1.4.2.1 UAT Planning 10 days 46SS Mon 8/6/18 Fri 8/17/18

1.1.1.4.2.2 UAT Execution 20 days 46 Mon 8/20/18 Mon 9/17/18

1.1.1.4.3 Release 4 Production Cut-over 23 days Mon 8/20/18 Thu 9/20/18

1.1.1.4.3.1 Production Cut-over Planning 5 days 49SS Mon 8/20/18 Fri 8/24/18

1.1.1.4.3.2 Implementation Plan 15 days 49SS Mon 8/20/18 Mon 9/10/18

1.1.1.4.3.3 Cut-over Execution 1 day 49FS+2 days Thu 9/20/18 Thu 9/20/18

1.1.2 STAR Referral System Release Schedule 147 days Mon 12/4/17 Fri 7/6/18

1.1.2.1 STAR Release 1 43 days Mon 12/4/17 Wed 2/7/18

1.1.2.1.1 STAR Release 1 Sprints 20 days Mon 12/4/17 Thu 1/4/18


1.1.2.1.1.2 Sprint 2 10 days 57 Mon 12/18/17 Thu 1/4/18

1.1.2.1.2 STAR Release 1 UAT 30 days Mon 12/18/17 Fri 2/2/18

1.1.2.1.2.1 UAT Planning 10 days 58SS Mon 12/18/17 Thu 1/4/18

1.1.2.1.2.2 UAT Execution 20 days 58 Fri 1/5/18 Fri 2/2/18

1.1.2.1.3 Release 1 Production Cut-over 23 days Fri 1/5/18 Wed 2/7/18

1.1.2.1.3.1 Production Cut-over Planning 5 days 61SS Fri 1/5/18 Thu 1/11/18

10


Start Projected

Finish

1.1.2.1.3.2 Implementation Plan 15 days 61SS Fri 1/5/18 Fri 1/26/18

1.1.2.1.3.3 Cut-over Execution 1 day 61FS+2 days Wed 2/7/18 Wed 2/7/18

1.1.2.2 STAR Release 2 43 days Mon 5/7/18 Fri 7/6/18

1.1.2.2.1 STAR Release 2 Sprints 20 days Mon 5/7/18 Mon 6/4/18



1.1.2.2.2 STAR Release 2 UAT 30 days Mon 5/21/18 Mon 7/2/18

1.1.2.2.2.1 UAT Planning 10 days 69SS Mon 5/21/18 Mon 6/4/18

1.1.2.2.2.2 UAT Execution 20 days 69 Tue 6/5/18 Mon 7/2/18

1.1.2.2.3 Release 2 Production Cut-over 23 days Tue 6/5/18 Fri 7/6/18


1.1.2.2.3.2 Implementation Plan 15 days 72SS Tue 6/5/18 Mon 6/25/18


1.1.3 Request Management System (RMS) Release Schedule

154 days Mon 11/6/17 Thu 6/21/18

1.1.3.1 RMS Release 1 43 days Mon 11/6/17 Fri 1/12/18

1.1.3.1.1 RMS Release 1 Sprints 20 days Mon 11/6/17 Wed 12/6/17


1.1.3.1.1.2 Sprint 2 10 days 80 Tue 11/21/17 Wed 12/6/17

1.1.3.1.2 RMS Release 1 UAT 30 days Tue 11/21/17 Tue 1/9/18

1.1.3.1.2.1 UAT Planning 10 days 81SS Tue 11/21/17 Wed 12/6/17

1.1.3.1.2.2 UAT Execution 20 days 81 Thu 12/7/17 Tue 1/9/18

1.1.3.1.3 RMS Release 1 Production Cut-over 23 days Thu 12/7/17 Fri 1/12/18

1.1.3.1.3.1 Production Cut-over Planning 5 days 84SS Thu 12/7/17 Wed 12/13/17

1.1.3.1.3.2 Implementation Plan 15 days 84SS Thu 12/7/17 Tue 1/2/18


1.1.3.2 RMS Release 2 43 days Mon 4/23/18 Thu 6/21/18

1.1.3.2.1 RMS Release 2 Sprints 20 days Mon 4/23/18 Fri 5/18/18



1.1.3.2.2 RMS Release 2 UAT 30 days Mon 5/7/18 Mon 6/18/18



1.1.3.2.3 RMS Release 2 Production Cut-over 23 days Mon 5/21/18 Thu 6/21/18


1.1.3.2.3.2 Implementation Plan 15 days 95SS Mon 5/21/18 Mon 6/11/18


1.1.4 Record Lookup System (RLS) and RLU Online Release Schedule

163.13 days

Mon 10/2/17 Thu 5/31/18

1.1.4.1 RLS Release 1 43 days Mon 10/2/17 Tue 12/5/17

1.1.4.1.1 RLS Release 1 Sprints 20 days Mon 10/2/17 Mon 10/30/17



1.1.4.1.2 RLS Release 1 UAT 30 days Mon 10/16/17 Thu 11/30/17


1.1.4.1.2.2 UAT Execution 20 days 104 Mon 10/30/17 Thu 11/30/17

1.1.4.1.3 RLS Release 1 Production Cut-over 23 days Mon 10/30/17 Tue 12/5/17

1.1.4.1.3.1 Production Cut-over Planning 5 days 107SS Mon 10/30/17 Mon 11/6/17

1.1.4.1.3.2 Implementation Plan 15 days 107SS Mon 10/30/17 Tue 11/21/17

1.1.4.1.3.3 Cut-over Execution 1 day 107FS+2 days Mon 12/4/17 Tue 12/5/17

1.1.4.2 RLS Release 2 43 days Mon 4/2/18 Thu 5/31/18

1.1.4.2.1 RLS Release 2 Sprints 20 days Mon 4/2/18 Fri 4/27/18



11


Start Projected

Finish

1.1.4.2.2 RLS Release 2 UAT 30 days Mon 4/16/18 Fri 5/25/18


1.1.4.2.2.2 UAT Execution 20 days 115 Mon 4/30/18 Fri 5/25/18

1.1.4.2.3 RLS Release 2 Production Cut-over 23 days Mon 4/30/18 Thu 5/31/18


1.1.4.2.3.2 Implementation Plan 15 days 118SS Mon 4/30/18 Fri 5/18/18


1.2 Department of Health and Human Services Release Schedules

150 days Mon 2/5/18 Thu 9/6/18

1.2.1 Newborn Screening (NBS) Release Schedule 150 days Mon 2/5/18 Thu 9/6/18

1.2.1.1 NBS Release 1 43 days Mon 2/5/18 Thu 4/5/18

1.2.1.1.1 NBS Release 1 Sprints 20 days Mon 2/5/18 Mon 3/5/18



1.2.1.1.2 NBS Release 1 UAT 30 days Tue 2/20/18 Mon 4/2/18



1.2.1.1.3 NBS Release 1 Production Cut-over 23 days Tue 3/6/18 Thu 4/5/18




1.2.1.2 NBS Release 2 43 days Mon 7/9/18 Thu 9/6/18

1.2.1.2.1 NBS Release 2 Sprints 20 days Mon 7/9/18 Fri 8/3/18



1.2.1.2.2 NBS Release 2 UAT 30 days Mon 7/23/18 Fri 8/31/18



1.2.1.2.3 NBS Release 2 Production Cut-over 23 days Mon 8/6/18 Thu 9/6/18




1.3 Michigan State Police 157 days Mon 10/16/17 Tue 6/5/18

1.3.1 FOIA Release Schedule 138 days Mon 11/13/17 Tue 6/5/18

1.3.1.1 FOIA Release 1 43 days Mon 11/13/17 Fri 1/19/18

1.3.1.1.1 FOIA Release 1 Sprints 20 days Mon 11/13/17 Tue 12/12/17

1.3.1.1.1.1 Sprint 1 10 days Mon 11/13/17 Tue 11/28/17

1.3.1.1.1.2 Sprint 2 10 days 151 Wed 11/29/17 Tue 12/12/17

1.3.1.1.2 FOIA Release 1 UAT 30 days Wed 11/29/17 Tue 1/16/18

1.3.1.1.2.1 UAT Planning 10 days 152SS Wed 11/29/17 Tue 12/12/17

1.3.1.1.2.2 UAT Execution 20 days 152 Wed 12/13/17 Tue 1/16/18

1.3.1.1.3 FOIA Release 1 Production Cut-over 23 days Wed 12/13/17 Fri 1/19/18

1.3.1.1.3.1 Production Cut-over Planning 5 days 155SS Wed 12/13/17 Tue 12/19/17

1.3.1.1.3.2 Implementation Plan 15 days 155SS Wed 12/13/17 Mon 1/8/18


1.3.1.2 FOIA Release 2 41 days Mon 4/9/18 Tue 6/5/18

1.3.1.2.1 FOIA Release 2 Sprints 20 days Mon 4/9/18 Fri 5/4/18



1.3.1.2.2 FOIA Release 2 UAT 30 days Mon 4/23/18 Mon 6/4/18



1.3.1.2.3 FOIA Release 2 Production Cut-over 21 days Mon 5/7/18 Tue 6/5/18


12


Start Projected

Finish


1.3.1.2.3.3 Cut-over Execution 1 day 166 Tue 6/5/18 Tue 6/5/18

1.3.2 Payment Processing Center (PPC) Release Schedule

129 days Mon 10/16/17 Wed 4/25/18

1.3.2.1 PPC Release 1 41 days Mon 10/16/17 Thu 12/14/17

1.3.2.1.1 PPC Release 1 Sprints 20 days Mon 10/16/17 Mon 11/13/17



1.3.2.1.2 PPC Release 1 UAT 30 days Mon 10/30/17 Wed 12/13/17


1.3.2.1.2.2 UAT Execution 20 days 175 Tue 11/14/17 Wed 12/13/17

1.3.2.1.3 PPC Release 1 Production Cut-over 21 days Tue 11/14/17 Thu 12/14/17


1.3.2.1.3.2 Implementation Plan 15 days 178SS Tue 11/14/17 Wed 12/6/17

1.3.2.1.3.3 Cut-over Execution 1 day 178 Thu 12/14/17 Thu 12/14/17

1.3.2.2 PPC Release 2 43 days Mon 2/26/18 Wed 4/25/18

1.3.2.2.1 PPC Release 2 Sprints 20 days Mon 2/26/18 Fri 3/23/18



1.3.2.2.2 PPC Release 2 UAT 30 days Mon 3/12/18 Fri 4/20/18



1.3.2.2.3 PPC Release 2 Production Cut-over 23 days Mon 3/26/18 Wed 4/25/18




1.4 Civil Service Commission 165 days Mon 1/22/18 Thu 9/13/18

1.4.1 Civil Service Assessment Application (CSAA) Release Schedule

165 days Mon 1/22/18 Thu 9/13/18

1.4.1.1 CSAA Release 1 43 days Mon 1/22/18 Thu 3/22/18

1.4.1.1.1 CSAA Release 1 Sprints 20 days Mon 1/22/18 Fri 2/16/18



1.4.1.1.2 CSAA Release 1 UAT 30 days Mon 2/5/18 Mon 3/19/18



1.4.1.1.3 CSAA Release 1 Production Cut-over 23 days Tue 2/20/18 Thu 3/22/18




1.4.1.2 CSAA Release 2 43 days Mon 7/16/18 Thu 9/13/18

1.4.1.2.1 CSAA Release 2 Sprints 20 days Mon 7/16/18 Fri 8/10/18



1.4.1.2.2 CSAA Release 2 UAT 30 days Mon 7/30/18 Mon 9/10/18



1.4.1.2.3 CSAA Release 2 Production Cut-over 23 days Mon 8/13/18 Thu 9/13/18




1.5 Department of Licensing and Regulatory Affairs Release Schedule

131 days Mon 1/8/18 Fri 7/13/18

1.5.1 Radiation Safety Data System (RSDS) and iPad App Release Schedule

43 days Mon 1/8/18 Fri 3/9/18

13


Start Projected

Finish

1.5.1.1 RSDS Release 43 days Mon 1/8/18 Fri 3/9/18

1.5.1.1.1 RSDS Release Sprints 20 days Mon 1/8/18 Mon 2/5/18



1.5.1.1.2 RSDS Release UAT 30 days Tue 1/23/18 Tue 3/6/18



1.5.1.1.3 RSDS Release Production Cut-over 23 days Tue 2/6/18 Fri 3/9/18


1.5.1.1.3.2 Implementation Plan 15 days 226SS Tue 2/6/18 Tue 2/27/18


1.5.2 Health Facilities Engineering System (HFES) Release Schedule

43 days Mon 3/12/18 Wed 5/9/18

1.5.2.1 HFES Release 43 days Mon 3/12/18 Wed 5/9/18

1.5.2.1.1 HFES Release Sprints 20 days Mon 3/12/18 Fri 4/6/18



1.5.2.1.2 HFES Release UAT 30 days Mon 3/26/18 Fri 5/4/18



1.5.2.1.3 HFES Release Production Cut-over 23 days Mon 4/9/18 Wed 5/9/18




1.5.3 Facilities Maintenance System (FMS) Release Schedule

43 days Mon 5/14/18 Fri 7/13/18

1.5.3.1 FMS Release 43 days Mon 5/14/18 Fri 7/13/18

1.5.3.1.1 FMS Release Sprints 20 days Mon 5/14/18 Mon 6/11/18



1.5.3.1.2 FMS Release UAT 30 days Tue 5/29/18 Tue 7/10/18



1.5.3.1.3 FMS Release Production Cut-over 23 days Tue 6/12/18 Fri 7/13/18




1.6 MiCaRS Release Schedule (DHHS, DOT, MSP, Treasury)

241.13 days

Mon 10/2/17 Thu 9/20/18

1.6.1 MiCaRS Warranty Release 63 days Mon 10/2/17 Mon 1/8/18

1.6.1.1 Warranty Release Sprints 40 days Mon 10/2/17 Thu 11/30/17

1.6.1.1.1 Sprint 1 10 days Mon 10/2/17 Mon 10/16/17

1.6.1.1.2 Sprint 2 10 days 258 Mon 10/16/17 Mon 10/30/17

1.6.1.1.3 Sprint 3 10 days 259 Mon 10/30/17 Tue 11/14/17

1.6.1.1.4 Sprint 4 10 days 260 Tue 11/14/17 Thu 11/30/17

1.6.1.2 Warranty Release UAT 30 days Tue 11/14/17 Wed 1/3/18

1.6.1.2.1 UAT Planning 10 days 261SS Tue 11/14/17 Thu 11/30/17

1.6.1.2.2 UAT Execution 20 days 261 Thu 11/30/17 Wed 1/3/18

1.6.1.3 Warranty Release Production Cut-over 23 days Thu 11/30/17 Mon 1/8/18

1.6.1.3.1 Production Cut-over Planning 5 days 264SS Thu 11/30/17 Thu 12/7/17

1.6.1.3.2 Implementation Plan 15 days 264SS Thu 11/30/17 Thu 12/21/17

1.6.1.3.3 Cut-over Execution 1 day 264FS+2 days Fri 1/5/18 Mon 1/8/18

1.6.2 MiCaRS Release 2 63 days Tue 1/16/18 Fri 4/13/18

1.6.2.1 Release 2 Sprints 40 days Tue 1/16/18 Tue 3/13/18

14


Start Projected

Finish

1.6.2.1.1 Sprint 1 10 days Tue 1/16/18 Mon 1/29/18

1.6.2.1.2 Sprint 2 10 days 271 Tue 1/30/18 Mon 2/12/18

1.6.2.1.3 Sprint 3 10 days 272 Tue 2/13/18 Tue 2/27/18

1.6.2.1.4 Sprint 4 10 days 273 Wed 2/28/18 Tue 3/13/18

1.6.2.2 Release 2 UAT 30 days Wed 2/28/18 Tue 4/10/18

1.6.2.2.1 UAT Planning 10 days 274SS Wed 2/28/18 Tue 3/13/18

1.6.2.2.2 UAT Execution 20 days 274 Wed 3/14/18 Tue 4/10/18

1.6.2.3 Release 2 Production Cut-over 23 days Wed 3/14/18 Fri 4/13/18

1.6.2.3.1 Production Cut-over Planning 5 days 277SS Wed 3/14/18 Tue 3/20/18

1.6.2.3.2 Implementation Plan 15 days 277SS Wed 3/14/18 Tue 4/3/18

1.6.2.3.3 Cut-over Execution 1 day 277FS+2 days Fri 4/13/18 Fri 4/13/18

1.6.3 MiCaRS Release 3 63 days Mon 4/23/18 Fri 7/20/18

1.6.3.1 Release 3 Sprints 40 days Mon 4/23/18 Mon 6/18/18

1.6.3.1.1 Sprint 1 10 days Mon 4/23/18 Fri 5/4/18

1.6.3.1.2 Sprint 2 10 days 284 Mon 5/7/18 Fri 5/18/18

1.6.3.1.3 Sprint 3 10 days 285 Mon 5/21/18 Mon 6/4/18

1.6.3.1.4 Sprint 4 10 days 286 Tue 6/5/18 Mon 6/18/18

1.6.3.2 Release 3 UAT 30 days Tue 6/5/18 Tue 7/17/18

1.6.3.2.1 UAT Planning 10 days 287SS Tue 6/5/18 Mon 6/18/18

1.6.3.2.2 UAT Execution 20 days 287 Tue 6/19/18 Tue 7/17/18

1.6.3.3 Release 3 Production Cut-over 23 days Tue 6/19/18 Fri 7/20/18

1.6.3.3.1 Production Cut-over Planning 5 days 290SS Tue 6/19/18 Mon 6/25/18

1.6.3.3.2 Implementation Plan 15 days 290SS Tue 6/19/18 Tue 7/10/18

1.6.3.3.3 Cut-over Execution 1 day 290FS+2 days Fri 7/20/18 Fri 7/20/18

1.6.4 MiCaRS Release 4 43 days Mon 7/23/18 Thu 9/20/18

1.6.4.1 Release 4 Sprints 20 days Mon 7/23/18 Fri 8/17/18

1.6.4.1.1 Sprint 1 10 days Mon 7/23/18 Fri 8/3/18

1.6.4.1.2 Sprint 4 10 days 297 Mon 8/6/18 Fri 8/17/18

1.6.4.2 Release 4 UAT 30 days Mon 8/6/18 Mon 9/17/18

1.6.4.2.1 UAT Planning 10 days 298SS Mon 8/6/18 Fri 8/17/18

1.6.4.2.2 UAT Execution 20 days 298 Mon 8/20/18 Mon 9/17/18

1.6.4.3 Release 4 Production Cut-over 23 days Mon 8/20/18 Thu 9/20/18

1.6.4.3.1 Production Cut-over Planning 5 days 301SS Mon 8/20/18 Fri 8/24/18

1.6.4.3.2 Implementation Plan 15 days 301SS Mon 8/20/18 Mon 9/10/18

1.6.4.3.3 Cut-over Execution 1 day 301FS+2 days Thu 9/20/18 Thu 9/20/18





$11,231,938.37



December 31, 2019


3 - 1 Year






☐ ☐ December 31, 2019


N/A

$430,000.00 $11,661,938.37

Effective September 12, 2017, the attached Statement of Work (SOW) document for Fire-PC to MiCaRS Interfaceand Enhancements is incorporated into this Contract and is increased by $430,000.00. Al other terms, conditions, specifications, and pricing remain the same. Per agency request, DTMB Procurement agreement, and State Administrative Board approval on 9/12/2017.

[email protected]

David Gabler

Malu Natarajan

[email protected]

John Leigh



*******1652

517-202-4625


(517) 284-7030

STATE

Pro

gra

m

Manager

Contra

ct

Adm

inistra

tor

CO

NTRACTO

R

DTMB-IT

517-284-4512


DTMB

N/A

DESCRIPTION

[email protected]

CONTRACT SUMMARY

Kunz, Leigh & Associates P.O. Box 760187 28081 Southfield Road Lathrup Village, MI 48076-0187 Phone: (248) 559-7910 Fax: (248) 559-8066 kunzleigh.com

Cover Letter Michigan Department of Natural Resources Attn: Lou Ann Fedewa Constitution Hall 4th Floor 525 W Allegan St. Lansing, MI 48929

Re: Fire-PC to MiCaRS Interface and Prescribed Burn

Dear Ms. Fedewa,

Program Services within the Michigan Department of Natural Resources, Forest Resources Division approached Kunz, Leigh & Associates (KL&A) about the possibility of developing an interface between Fire-PC and the Michigan Cashiering and Receivable System (MiCaRS). Program Services, invoices the responsible party of a fire and creates a receivable. The current process for invoicing responsible parties, managing invoices, and tracking payments is done manually between Fire-PC and MiCaRS. KL&A participated in meetings with Program Services, Fire Management, and the Department of Technology, Management and Budget (DTMB) to develop an interface design that will allow Fire-PC and MiCaRS to interact systematically.

During our meetings to understand Fire-PC and the design for an interface with MiCaRS, KL&A discovered that Fire Management, the owner of Fire-PC would also like to enhance Fire-PC to include a module to automate their Prescribed Burn process. Prescribed Burn consists of two parts: a plan and a report. The development and maintenance of Prescribed Burn Plans and Reports is manual and requires duplication of data between a fire plan and report, and from fire to fire. Following the meetings to scope the Prescribed Burn module, KL&A is excited to propose a programmatic solution for Prescribed Burn and pleased to provide this Statement of Work, describing how we can deliver a web-based application that will modernize Fire-PC to include a robust interface with MiCaRS and the automation of the Prescribed Burn process.

The attached Statement of Work explains the project background, objectives, scope of work, project approach, project schedule and fixed project cost.

If you have any questions, please contact John Leigh at 517-202-4625.

Sincerely,

John Leigh KL&A Partner

Fire-PC to MiCaRS Interface and Enhancements

Statement of Work

Prepared for:

Michigan Department of Natural Resources 525 W. Allegan St. Lansing, MI 48913

Prepared by:

Kunz, Leigh & Associates 28081 Southfield Road

Lathrup Village, MI 48076-2816

v1.0 July 19, 2017

©2017 Kunz, Leigh & Associates 5

Proposal Signatures Name/Title Signature Date

John K. Leigh, KL&A Partner

07-19-2017

Fire-PC to MiCaRS Interface and Enhancements Statement of Work

6 v1.0 KL&A


KL&A v1.0 7

Table of Contents 1.0 Project Identification ....................................................................................................................... 9 2.0 Project Objective .............................................................................................................................. 9 3.0 Background ...................................................................................................................................... 9 4.0 Scope of Work ................................................................................................................................ 10

4.1 Proposed Solution ................................................................................................................... 10 4.1.1 Fire-PC to MiCaRS Interface ............................................................................................ 10

4.1.1.1 Establish Invoice .................................................................................................. 11 4.1.1.1.1 Use Case ........................................................................................................ 11 4.1.1.1.2 Invoice Interface ............................................................................................ 12

4.1.1.2 Invoice Inquiry ..................................................................................................... 13 4.1.1.2.1 Use Case ........................................................................................................ 13 4.1.1.2.2 Invoice Detail ................................................................................................. 13

4.1.2 Fire-PC Technology Upgrade ........................................................................................... 13 4.1.3 Prescribed Burn Module ................................................................................................. 15

4.1.3.1 Module Goals ....................................................................................................... 17 4.1.3.2 Functional Overview ............................................................................................ 17

4.1.3.2.1 Dashboard ..................................................................................................... 18 4.1.3.2.2 Burn Plans ...................................................................................................... 18 4.1.3.2.3 Burn Report ................................................................................................... 19 4.1.3.2.4 Security .......................................................................................................... 20

4.2 Project Approach ..................................................................................................................... 21 5.0 Schedule ......................................................................................................................................... 23 6.0 Deliverables ................................................................................................................................... 23 7.0 Acceptance Criteria ........................................................................................................................ 24 8.0 Project Control and Reports .......................................................................................................... 24 9.0 Cost ................................................................................................................................................ 25 10.0 Payment Schedule..................................................................................................................... 26

10.1 Payment Address ................................................................................................................ 28 11.0 Maintenance and Support ........................................................................................................ 28 12.0 Project Contacts ........................................................................................................................ 28 13.0 Roles and Responsibilities ......................................................................................................... 28

13.1 Location of Work ................................................................................................................ 30 13.2 Hours of Operation ............................................................................................................. 30

14.0 Assumptions .............................................................................................................................. 31


8 v1.0 KL&A

List of Tables Table 1. Fire-PC Functionality .............................................................................................................. 14 Table 2. Fire-PC Open Items ................................................................................................................. 15 Table 3. Deliverables ............................................................................................................................ 23 Table 4. Fire-PC to MiCaRS Interface and Enhancement Cost ............................................................. 25 Table 5. Payment Schedule .................................................................................................................. 26 Table 6. Roles and Responsibilities ...................................................................................................... 28 Table 7. Project Assumptions ............................................................................................................... 31

List of Figures Figure 1. Burn Plan and Report Process ............................................................................................... 16 Figure 2. Prescribed Burn Module Site Map ........................................................................................ 17 Figure 3. Scrum Development Process ................................................................................................ 21

Background

KL&A v1.0 9

1.0 Project Identification Effective July 2017, the Parties agree that all work to be performed will be pursuant to the Statement of Work and to the terms of the Kunz, Leigh & Associates (“Contractor”) Contract 071B4300022. Any changes to the scope of Services described herein shall be pursuant to a modification to this Contract Amendment.

The services described herein (“Services”) and deliverables identified below (“Deliverables”) shall be delivered on a fixed price basis, which means a predefined project model where the Contractor provides the Services, including any Deliverables, for a set fee.

2.0 Project Objective Both Financial Services and Fire Management within the Michigan Department of Natural Resources (DNR) would like to bring efficiencies to the Fire-PC application and Prescribed Burn process. Therefore, DNR would like to enhance Fire-PC to include a systematic interface with the Michigan Cashiering and Receivable System (MiCaRS), and enhance Fire-PC with a new module to handle the Prescribed Burn process. Along with each of these major enhancements this Statement of Work proposes modernizing the Fire-PC application by moving it from a client/server platform to a web platform. Modernization of Fire-PC follows the Department of Technology, Management and Budget (DTMB) roadmap for technology improvement and makes Fire-PC easier to maintain and enhance in the future.

3.0 Background The proposed project evolved from a discussion between DNR Financial Services and the Contractor to determine the viability of an interface between Fire-PC and MiCaRS. DNR explained the need to move away from manually creating and tracking receivables in MiCaRS. Therefore, DNR would like an interface between the two systems to communicate and manage receivable information. Financial Services was aware of MiCaRS interfaces with other DNR and State of Michigan Program systems for creating and managing receivables and asked the Contractor to explain the details and complexity of undertaking such an endeavor.

While discussing the interface changes to Fire-PC, Fire Management inquired about further enhancements to Fire-PC to include their Prescribed Burn process. Fire Management, Financial Services, DTMB and the Contractor met to discuss the details and developed enough understanding to provide an accurate scope. During the same discussions, the Contractor learned that such changes to Fire-PC would require an upgrade of the Fire-PC platform from client/server to web.


10 v1.0 KL&A

4.0 Scope of Work

4.1 Proposed Solution The proposed solution can be divided into three (3) efforts: an interface between Fire-PC and MiCaRS, a technology upgrade for Fire-PC, and the addition of the Prescribed Burn module to Fire-PC. The remainder of this Section provides detail about the individual efforts.

4.1.1 Fire-PC to MiCaRS Interface The primary goal of the Fire-PC to MiCaRS interface is to provide a systematic method for generating receivables in MiCaRS. It will also allow Fire-PC to perform MiCaRS status inquiries about receivables. KL&A is proposing service based interfaces for creating and tracking receivables. The current process for creating, managing, and tracking the status of invoices is done manually. To achieve a systematic interface between Fire-PC and MiCaRS requires services to be performed on the MiCaRS side and enhancements to be performed on Fire-PC for consumption of the MiCaRS services. In this case, the majority of the MiCaRS services required are already in place.

As Fire-PC is upgraded (Section 4.1.2) to a web application, Fire-PC will be enhanced to call the MiCaRS services required to create a receivable and display the status of a receivable.

Scope of Work

KL&A v1.0 11

4.1.1.1 Establish Invoice

4.1.1.1.1 Use Case

Establishing Receivable

• Fire-PC System creates an accrual based receivable.

o The final approver in the Fire Solution will have the ability to generate an invoice after the approval process completes. An e-mail will be sent to the MiCaRS business person in charge of printing to notify that a new Fire invoice has been created and needs to be printed.

• Fire-PC System calls the "Create Fire Invoice" web service on MiCaRS, providing the Fire Report Number, fee type, custom invoice message built dynamically from Fire-PC database and line items with amounts.

• MiCaRS creates a MiCaRS invoice and links the Fire Report Number to the MiCaRS invoice number.

• MiCaRS uses the Fire-PC Responsible Party ID provided to link to existing customer if possible, otherwise a new customer is created with provided information and record number.

• MiCaRS user prints and sends the invoice to the customer.

• MiCaRS establishes receivable in SIGMA if the program is configured to do so.

• After delinquency timeline MiCaRS AR worker generates invoice and letter if the program is configured to do so.

Check with a MiCaRS invoice number is received

• MiCaRS Cashier links deposit to invoice and updates receivable in SIGMA.


12 v1.0 KL&A

4.1.1.1.2 Invoice Interface

A MiCaRS web service will be made available to establish an accrual based receivable on behalf of Fire-PC.

Input:

• Division Code to be used for establishing the invoice. This is used with the program code to determine the accounting.

• Program Code to be used for establishing the invoice. This also dictates the accounting that will be used for the invoice.

• Fire Report Number (will be mapped to Reference Number in MiCaRS)

• Customer Information (Name and Mailing Address)

• Fire-PC Responsible Party identified (Account number or other ID from Fire-PC)

• Invoice Date

• Invoice Notes (Text to be included on MiCaRS invoice / delinquency letter)

• Note Indicator (a flag that will indicate to MiCaRS to Overwrite the default note that is configured for the program or Append the included note to the end of the default note)

• List of Line Items:

o Amount

o Description (will be included on MiCaRS invoice / delinquency letter)

Output:

• MiCaRS Invoice Number (for reference purposes)

• Total Amount (for validation)

Scope of Work

KL&A v1.0 13

4.1.1.2 Invoice Inquiry

4.1.1.2.1 Use Case

Running Invoice Query

• Fire-PC User navigates to Responsible Party screen.

• Fire-PC System calls the “Complete Invoice” web service on MiCaRS, providing the MiCaRS Invoice Number.

• MiCaRS runs a query based on the Invoice Number provided and returns the data.

• Fire-PC System displays MiCaRS Invoice data including original invoice, adjustments, interest, and amount due.

4.1.1.2.2 Invoice Detail

A MiCaRS web service will be made available to query the current state of an Invoice. The method, get Invoice, will provide Fire-PC with all invoice details including a current balance.

Input:

• MiCaRS Invoice Number (required)

MiCaRS Processing Rules:

• Invoice Number exists in MiCaRS

Output:

• List<invoiceHeader> invoiceHeader

o List<invoiceDetails> invoiceDetails

o List<invoiceAccounts> invoiceAccounts

o List<invoiceActivity> invoiceActivity

4.1.2 Fire-PC Technology Upgrade The Fire-PC technology upgrade migrates Fire-PC from a client/server application to a web application. The upgraded application will be built using Microsoft ASP.NET utilizing the existing SQL Server database.


14 v1.0 KL&A

The upgraded application will include all the legacy Fire-PC functionality and 6 additional reports (to be defined) using a web platform. The following table includes the Fire-PC functionality.

Table 1. Fire-PC Functionality

Fire-PC Functionality Reports

Fire summary by station

Fires by station/form of heat of ignition

Fires by station/ignition factor

Fires by cause/residence county

DNR labor by station

Keyman labor by station

Vendors by service

Equipment by station

Annual Fire Report Fires

List

View (pdf)

Fire Edit

Dates

Location

Acreage

Behavior

Cause

Responsibility

Railroad

Cost

Keyman Labor

Vendors

DNR Labor

DNR Equipment

Contributed Labor

Narrative

Files

Fire Report Status

Approval Section

Scope of Work

KL&A v1.0 15

The contractor will also address a list of open items at no additional charge. Those items are listed in the table below.

Table 2. Fire-PC Open Items

Open Items Listed by Priority High Priority

Spell check for narrative page

Correction of responsible party defaulting to today date

Report return for update needed-not approved-e mail to sender-option for reviewers only

Tab to automatically print suppression bill and interface with MiCaRS

Permission for Resource Protection Manager to delete report Add to location page-drop down box titled assist from other DNR stations with drop down list of all stations (need to allow for multiple entries) Medium Priority Remove Marquette station and others from station choices/still need ability to show stats prior to 2009 Add Trout Lake & Mt. Pleasant to weather station options Misc. Cause-add ash dumping Misc. cause-military Zone dispatch-if yes add name of zone from drop down box Add amount billed & date collected (allow multiple dates for "payment plans") Law Enforcement report was followed up on (reminder) - Cause screen Low Priority Remove $$ amount from contributed labor (currently wide range inputted-does not provide accurate data)

4.1.3 Prescribed Burn Module The Prescribed Burn module of the Fire Management Solution addresses the DNR business process and management of fire use in ecosystems. This objective is achieved through the creation, execution, and guidance of Prescribed Burn plans and reports, which law enforcement and local fire departments use and complete.

The business process begins with the creation of a Prescribed Burn Plan for a specific location by Michigan DNR officials. This plan includes a location, safety logistics, and administrative information. The Burn Plan is then evaluated for feasibility during burn season by officials. Various factors are evaluated for safety and once a Burn Plan is approved, selected, and executed a Burn Report is created after the fact by the Fire Boss.


16 v1.0 KL&A

The Burn Report contains observations and data about the burn and can be used to inform future Burn Plans.

Figure 1. Burn Plan and Report Process

The current plan and report process is completed entirely with a paper/manual process. The data collected is not accessible for reporting and metric purposes. Microsoft Word templates have been created to facilitate form completion. These forms (plan and report) will represent the starting point for the system database design.

Scope of Work

KL&A v1.0 17

4.1.3.1 Module Goals • Store plan and report data in a database.

• Leverage existing ecosystem of fire applications and databases

o Source Data

Equipment

Approvers

o Expose Data

Plans

Reports

• Improve efficiency of the current business process

o Reduce duplicate data entry

o Approval / Workflow

o Historical access

4.1.3.2 Functional Overview

There are three main functional areas of the prescribed burn module: Dashboard, Burn Plan Management, and Burn Report Management. System administration and reporting will be added to the Fire Management areas.

Figure 2. Prescribed Burn Module Site Map


18 v1.0 KL&A

In general, whenever a multiple-choice section is present on the current paper form of the plans and reports, that data will be placed in a Lookup Value so that it can be dynamically maintained by a system administrator of the Fire application.

4.1.3.2.1 Dashboard

The dashboard area is responsible for workflow management functionality. It will show plans and reports needing approval as well as provide a bird’s eye view of activities taking place around Prescribed Burns, such as modifications and creations of plans and reports.

4.1.3.2.2 Burn Plans

Burn Plans represent a proposal to perform a controlled burn at a specific location. Burn Reports are associated with Burn Plans. A Burn Plan contains many sub sections of data and needs to be created, edited, duplicated and approved by several managers.

A Burn Plan can be broken into the following sections with each having a narrative and/or comment input:

Main Data

The following data represents pages 1 through 4 of the current Burn Plan form. This information is the introduction and context for the burn, which includes the following areas:

• Location

• Management Objectives

• Specific Objectives

• Type of Burn Needed

• Concerns

• Approvals

• Review Comments

• Smoke Dispersion Map / Comments

• Photos

Prescription Parameters

The Prescription Parameters represent the type of fuels present at the site and a matrix of possible Initial Spread Index (ISI) or other outputs, stored on page 5 of the current form. This ISI matrix is used for searching for appropriate Burn Plans for execution during a burn season. There is a potential to generate this matrix algorithmically.

Limits

Seasonal limits based on weather information, currently on page 6 of the Burn Plan form, will be tracked including wind directions and dates to include these limits.

Scope of Work

KL&A v1.0 19

Ignition Pattern and Firing Equipment

The firing equipment and acceptable ignition patterns as well as explanations will be stored. This data is currently on page 6 of the Burn Plan.

Holding, Mop-Up and Patrol Plan

The data in this section, which is currently on page 6 of the Burn Plan form, represents post burn activities.

Resource Requirement Summary

The equipment and personnel to be used on the plan will be tracked. If possible, this information will be pulled from existing applications or databases that track available equipment and resources. Currently this information is stored on page 7 of the Burn Plan.

Cooperator and public contact

State, federal and local agency contacts will be stored in this section as well as specific actions to take place related to the plan. Currently this information is stored on page 8 of the Burn Plan.

Training, Safety and Medical

Narratives will be stored in this section. Currently this information is stored on page 8 of the Burn Plan.

Complexity Rating

The Complexity Rating for various factors and elements is tracked in this section along with the justification for the complexity, if applicable. This information is currently tracked on page 9 of the Burn Plan.

Burn Day Checklist and Briefing

The burn day decision checklist as well as briefing sheet are used by Burn Bosses which will be generated as an editable PDF that can be created for tracking of activities leading up to the burn. The checklist and briefing sheet are currently on pages 10-11 of the Burn Plan.

Maps

PDF or image files, along with comments, can be uploaded and associated with the Burn Plan. This information is currently on pages 12-13 of the Burn Plan. The system will not generate a map, but will allow a user to upload image or PDF files that were generated outside of the system.

4.1.3.2.3 Burn Report

Once a Burn Plan has been executed a report must be filed. Multiple reports for one plan may be entered if a burn spans multiple days.


20 v1.0 KL&A

A report is broken up into the following sections:

• Main Data

o Chronology o Acres Proposed o Burned o CFFDRS o Fuel Type o Burned % o Date/Status/Actions List

• Weather Forecast

o Previous o Forecasted o Forecast narrative o Field Obs

• Observations

o Foliar Moisture o Smoke Management o Fuel Consumption o Fire Effects o General Observations and Recommendations

• Personnel

• Photos

• Go/No-Go Checklist

In general, the data stored will follow the Prescribed Burn Report form used today. The weather forecast information will be pulled from weather station historical data if a usable API can be provided.

Personnel information will be pulled from the appropriate auxiliary systems if an API can be provided as well.

Reports

Up to 5 reports will be developed to assist in the management and visualization of the plan and report data.

4.1.3.2.4 Security

There will be three types of users for prescribed burn data: administrators, general users, and approvers. Administrators will have access to dynamic lookup values and user role data. General Users will have the ability to edit plans and reports. Approvers will have access to approve plans and reports. There will not be a read-only role who has access to only view data.

Scope of Work

KL&A v1.0 21

4.2 Project Approach The approach used for a project is an important part of a project’s success. Of course, a project will have a better opportunity of success if it has the required funding, skilled resources, executive support, limited impediments, and limited constraints. However, a project can have all the right ingredients, but still fail if the project does not have a clear project approach.

KL&A subscribes to Scrum (Agile) development methodology because it has proven to be effective and efficient, resulting in the implementation of functioning software within weeks or months, rather than years. Scrum development encompasses the principle of iterative releases called “sprints,” where all phases of the software development life cycle (SDLC) are executed for each sprint, including requirements elicitation and definition, design, software construction, testing, and implementation. Additionally, KL&A collaborates with our clients and stakeholders throughout each sprint with activities such as joint application design (JAD) sessions, requirement prioritization sessions, product demonstrations, and user acceptance testing (UAT) of each feature.

Figure 3. Scrum Development Process

KL&A staff are Scrum Alliance, Certified Scrum Masters or Certified Scrum Product Owners, depending upon their job functions.


22 v1.0 KL&A

Major benefits of Scrum include:

• Functioning software at the end of each sprint, with which users can interact and test. Feedback can be acted upon in the next sprint, ensuring that each function fully satisfies your business needs and meets your user’s expectations.

• The ability to re-prioritize work as development occurs. In the ever-changing world of enterprise and government regulations, priorities may shift for a variety of reasons. Scrum provides the flexibility to assess and modify priorities at the beginning of each sprint.

• Incremental testing eliminates long test cycles before implementation and minimizes the risk of defects reaching end users. Rather than have a lengthy test cycle at the end of the development, that could result in a long defect repair and re-test cycle, testing is performed as part of each sprint. This approach significantly reduces the chance of defects reaching the end users.

• Reduced need for formal training. Business users receive product demonstrations before a feature is released, they test the feature in a User Acceptance Test cycle, and they can use the feature, while other features are being developed. When the fully functional system is completed, the users are already familiar with all features implemented throughout the preceding iterations of development.

At the beginning of the project, a KL&A Project Manager will meet with DNR and DTMB to review the proposed solution, define project parameters, and roles and responsibilities. KL&A will use the findings from this kick-off meeting to deliver a Project Charter, Project Management Plan, and Project Schedule for approval.

During the initiation phase KL&A will work with DNR and DTMB to develop an initial product backlog. KL&A uses Jira as its development and issue tracking tool which is also where the product backlog lives. KL&A will also provide identified DNR and DTMB personnel with access to Jira for backlog prioritization, discussed later, and to optionally record product defects and enhancement requests. KL&A will also provide any necessary support in the use of the tool.

Development will be executed through a series of sprints. Generally, sprints are two weeks long, but may be adjusted if necessary. At the beginning of each sprint, an identified DNR resource will review the backlog of requirements and verify or modify the priority of the outstanding requirements. KL&A’s development team then conducts a sprint planning session, where KL&A will determine how many of the top priorities can be completed within the sprint. KL&A will solidify and document Function and System Design for the selected requirements/features.

When code development for the sprint is complete, KL&A will deploy the function(s) to a staging/testing environment. KL&A will perform functional testing and system integration testing (SIT), create User Acceptance Testing (UAT) Test Cases, and load the UAT test cases into Jama, our requirements and test tracking tool. Identified DNR business users, with support from KL&A, will execute the test cases and provide feedback in Jama. Jama is an easy-to-use, web-based tool. Users simply click pass or fail next to each step of the test case, and if there is a failure, enter comments

Deliverables

KL&A v1.0 23

explaining the failure. Before the sprint is closed, KL&A will repair any defects found during UAT to the satisfaction of DNR. A defect is defined as malfunctioning code or code that does not meet the defined requirement. Any feedback that is not a defect will be entered into Jira as an enhancement request and will be reviewed with the appropriate DNR personnel. Enhancement requests that affect scope, schedule, or budget will be diverted to an agreed-upon change control process. Once the UAT cycle is complete, KL&A will deploy the sprint code to the production server and will generate requirements and traceability information.

The Design, Requirements, and Traceability documents will be living documents that are updated with the information created in each sprint.

KL&A will facilitate regular status meetings at an agreed upon interval and will provide meeting agendas and meeting minutes in an agreed upon format.

When all requirements have been implemented and the final round of UAT is successfully completed, project close-out will commence. Close-out entails formal sign-off.

5.0 Schedule During project initiation, the contractor will work with DNR and DTMB to developed a detailed project schedule (see Attachment A for a preliminary schedule). The contractor has allotted 2 weeks for project initiation, 12 weeks for Fire-PC Upgrade and interface to MiCaRS, and 28 weeks for Prescribed Burn.

6.0 Deliverables For the proposed project, the following deliverables will be created.


Deliverable Project Charter

Project Management Plan Project Schedule Product Backlog

Functional Design Document System Design Document

Maintenance Plan Software Configuration Management Plan

Test Plan Test Type Approach and Report

Test Cases


24 v1.0 KL&A

Deliverable Enterprise Architecture Solution Assessment

Security Plan and Assessment Requirements Traceability Matrix

Transition Plan Installation Plan

Training Plan Application Code

Production Implementation

7.0 Acceptance Criteria The agencies responsible for providing acceptance of Fire-PC and enhancements for DNR will indicate acceptance of the application through a written acceptance and sign-off of the project milestones outlined in the payment schedule.

8.0 Project Control and Reports KL&A will track and report all project status, project risks and project issues. The project will have a weekly team meeting, bi-weekly leadership meeting and monthly steering committee meeting.

For each of the meetings a status report will be provided which will include the following information:

• Dates of the reporting period

• Contractor name

• DTMB manager name

• P.O. Number

• Project name

• Work authorization number

• Dashboard level project schedule

• Issues

• Risks

• Major accomplishments for the reporting period

• Work completed during the reporting period including who completed the work

• Work for the next reporting period including who will complete the work

Cost

KL&A v1.0 25

The status reports will be provided in a Microsoft Word or PDF format. The base document for the status reports will follow the PMM-0013 template. The documents may change based on the individual project team needs, approved by the State.

The project team will also use a formal process for change control and bug control. The change control process will be documented and elaborated upon in the Project Management Plan and will follow the SUITE process.

Defect control will be documented and elaborated upon in the Test Plan and Test Type Approach documents.

9.0 Cost Table 4. Fire-PC to MiCaRS Interface and Enhancement Cost

Milestone Activity Cost Initiation Kickoff $2,000.00 Project Charter $2,000.00 PMP $3,000.00 Project Schedule $3,000.00 Bootstrapping/Initial Backlog $14,400.00

Fire-PC Product Backlog Grooming $3,000.00 Sprint Planning $3,660.00 Application Development $77,760.00 Internal QA $14,400.00 Sprint Review $3,660.00 Sprint Retrospective $3,660.00

Burn Product Backlog Grooming $7,000.00 Sprint Planning $8,540.00 Application Development $181,440.00 Internal QA $33,600.00 Sprint Review $8,540.00 Sprint Retrospective $8,540.00

Fire-PC / Burn SEM-0301 Maintenance Plan $2,000.00 SEM-0302 Software Configuration Management Plan $2,000.00 SEM-0501 Functional Design $5,000.00


26 v1.0 KL&A

Milestone Activity Cost SEM-0601 Conversion Plan $0.00 SEM-0602 Test Plan $2,000.00 SEM-0603 Test Type Approach and Report $3,000.00 SEM-0604 System Design Document $5,000.00 eMichigan Review $5,000.00 Enterprise Architecture (EA) Assessment $2,000.00 Project Security Plan and Assessment (DTMB-0170) $10,000.00 Requirements Traceability Matrix $1,000.00

Testing Installation and Configuration of QA Environment $3,440.00 User Acceptance Testing Support $8,000.00

Training SEM-0703 Training Plan $2,000.00 Training Guides $3,000.00 Training Execution $1,000.00

Implementation SEM-0701 Transition Plan $500.00 SEM-0702 Installation Plan $4,160.00 Installation and Configuration of Production Environment $3,440.00 Total Cost $440,740.00 Less Discount $10,740.00 Final Cost $430,000.00

10.0 Payment Schedule KL&A recommends payment by deliverable.

Table 5. Payment Schedule

Milestone Deliverables relating to Milestone Acceptance Criteria Cost I. Initiation / Sprint 0

Kickoff Project Charter PMP Project Schedule Initial Backlog

Signatures provided by

authorized signer.

$24,400

Payment Schedule

KL&A v1.0 27

Milestone Deliverables relating to Milestone Acceptance Criteria Cost II. Fire-PC / MiCaRS

Product Backlog Grooming Sprint Planning Application Development Internal QA Sprint Review Sprint Retrospective

The application built and ready for

entry into final UAT.

$106,140

III. Prescribed Burn

Product Backlog Grooming Sprint Planning Application Development Internal QA Sprint Review Sprint Retrospective

The application built and ready for

entry into final UAT.

$247,660

IV. Implementation

SEM-0301 Maintenance Plan SEM-0302 Software Configuration Management Plan SEM-0501 Functional Design SEM-0601 Conversion Plan SEM-0602 Test Plan SEM-0603 Test Type Approach and Report SEM-0604 System Design Document eMichigan Review Enterprise Architecture (EA) Assessment Project Security Plan and Assessment (DTMB-0170) Requirements Traceability Matrix Installation and Configuration of QA Environment User Acceptance Testing Support SEM-0703 Training Plan Training Guides Training Execution SEM-0701 Transition Plan SEM-0702 Installation Plan Installation and Configuration of Production Environment

All functionality in production and

validated.

$51,800


28 v1.0 KL&A

10.1 Payment Address The KL&A payment address is:

Kunz, Leigh & Associates P.O. Box 760187 28081 Southfield Road Lathrup Village, MI 48076-0187

11.0 Maintenance and Support Following the last production cut-over (Prescribed Burn) the contractor will provide a year of maintenance and support at a fixed price cost of $25,000 for fiscal year 2019. Maintenance and support for fiscal year 2020 and moving forward will be evaluated on a year by year basis to understand support needs and adjust cost accordingly.

12.0 Project Contacts The Single Point of Contact (SPOC) for this project is:

Martin Tompkins [email protected] 517-202-0329

13.0 Roles and Responsibilities Table 6. Roles and Responsibilities

Role Responsibility KL&A Project Manager • Facilitate meetings

• Prepare status reports • Maintain project schedule • Communicate with DNR and DTMB • Manage development team • Provide a Project Charter • Provide a Project Management Plan


Roles and Responsibilities

KL&A v1.0 29

Role Responsibility KL&A Developer(s) • Develop the application

• Work with eMichigan to ensure compliance • Work with DTMB to ensure ADA Certification • Unit testing • Code reviews

KL&A Business Analyst • Write PMM and SEM document, described in • Write/update the end-user manual • Write test cases and test plans • Execute System Integration Testing • Facilitate User Acceptance Testing with DNR personnel

DNR Product Owner • Prioritize product backlog before each Sprint • Resolve project impediments • Attend JAD session • Attend product demos • Optionally attend Sprint planning meetings • Provide written acceptance of deliverables

DNR SMEs • Attend requirements and joint application design sessions • Attend ad-hoc meetings • Answer question pertaining to DNR processes via email

within 24 hours DNR Test Lead • Identify UAT testers for each Sprint and release

• Review test results with Product Owner • Attend product demos and all testing-related meetings • Provide input to test case development

DNR UAT Testers • Perform User Acceptance Testing, using test cases provided by KL&A

• Record testing results in Jama • Attend product demo and testing-related meetings, as

identified by the DNR Test Lead DNR Project Stakeholders • Attend applicable requirements gathering and joint

application design sessions • Provide input, where appropriate, to project decisions


30 v1.0 KL&A

Role Responsibility DTMB PM • Act as the State’s SPOC for the Contractor in regard to this

project • Obtain the relevant DTMB, DNR, and/or State

department/division concurrence(s) for any Contractor requested change or standard deviation to this contract

• Provide State facilities, as needed • Coordinate the State resources necessary for the project • Facilitate coordination between various external

contractors • Facilitate communication between different State

departments/divisions • Provide acceptance and sign-off of deliverable/milestone • Review and sign-off of timesheets and invoices • Resolve project issues • Escalate outstanding/high priority issues • Utilize change control procedures • Conduct regular and ongoing review of the project to

confirm that it meets original objectives and requirements • Document and archive all important project decisions • Arrange, schedule and facilitate State staff attendance at

all project meetings

13.1 Location of Work KL&A maintains two offices in the State of Michigan, one of which is located in Okemos, MI to serve the Lansing area. KL&A expects the development work to be completed at the Okemos office, with on-site visits to State facilities for meetings or other project activities. KL&A’s Okemos office has conference rooms available, should the State desire KL&A to host project meetings.

13.2 Hours of Operation KL&A project staff will be available to perform project activities Monday through Friday, 8AM to 5PM, and to be available after-hours on an as-needed basis. KL&A observes the same holiday schedule as the State of Michigan.

Assumptions

KL&A v1.0 31


Project Assumptions This project will be developed with the Scrum (Agile) methodology, delivering functionality through a series of releases; each release will provide a project milestone. The project contains dependencies on DTMB for hardware and for security approvals that can impact the completion date of the project. DTMB will provide a development, test, and production web server. DTMB will provide KL&A and DNR personnel with the necessary credentials to access the servers. DNR is responsible for the cost of these servers, which is payable to DTMB. KL&A observes the following non-working holidays, Memorial Day, Independence Day, and Labor Day, Thanksgiving and the day after, Christmas Eve and Christmas Day. All other non-weekend calendar days, and non-State holidays, are treated as work days, with the assumption that both KL&A and DNR stakeholders are available to complete project-related tasks. This proposal is a fixed-price bid. Change requests approved by DNR or DTMB will affect the price and schedule as defined within the request of change (RFC). KL&A will provide test cases and test plans for user acceptance testing (UAT) prior to each release and will facilitate UAT. UAT will be concluded within 5 business days of each Sprint release. Issues found during testing will be recorded in JAMA. Any failures reported during UAT that KL&A deems outside the scope of this project will be handled through a “change request” process, in which KL&A will submit the request for change (RFC) to DTMB. DTMB will be responsible for evaluating and approving or declining any RFC initiated by KL&A or the DNR, and the project schedule, pricing, and payment schedule will be updated accordingly. DTMB will be responsible for deploying the releases to production. KL&A will initiate the release process via an RFC. KL&A will be responsible for deploying releases to the Dev and Test servers. KL&A will use GIT Hub for internal source control. KL&A will deliver source code to DTMB to deploy to Team Foundation Server. KL&A will deliver source code with each release deployment. KL&A will work with eMichigan to ensure Fire-PC is compliant with eMichigan standards. KL&A will work with DTMB to ensure that Fire-PC will adhere to Audit ADA Certification.

CHANGE NOTICE NO, 13 TO CONTRACT NO. 07164300022

Program Managers

for Multi�Agency and Statewide Contracts





CONTRACT SUMMARY


CHANGE(S) NOTED BELOW



N/A





☐ ☐ December 31, 2019


$10,941,138.37 $290,800.00 $11,231,938.37

DESCRIPTION

Effective July 17, 2017, the attached Statement of Work for development of Vegetative Management System Michigan Wood Module (VMS Mi Wood) is incorporated into this Contract and is increased by $290,800.00. All other terms, conditions, specifications, and pricing remain the same per Contractor proposal, Agency agreement and DTMB approval.

STATE

Pro

gra

m

Manager

David Gabler DTMB-IT

517-284-4512

[email protected] Contra

ct

Adm

inistra

tor

Malu Natarajan DTMB

(517) 284-7030

[email protected]

CO

NTRACTO

R




John Leigh

517-202-4625

[email protected]

*******1652




MICHIGAN DEPARTMENT OF TECHNOLOGY,

MANAGEMENT AND BUDGET IT SERVICES

STATEMENT OF WORK

Project Title: VMS Michigan Wood Module (VMS Mi Wood)

Period of Coverage:9/18/2017 – 5/9/2019

Requesting Department: Natural Resources

Date: 7/7/2017

Agency Project Manager: Doug Heym

Phone: 284-5867

DTMB Project Manager: Robin Krzciok

Phone: 335-3211

Brief Description of Services to be provided:

BACKGROUND: The Forest Resources Division collects data on entities involved in the forest products industry as part of the Michigan Wood (Mi Wood) project. The goal of the program is to assist and expand the forest products industry by providing useful data. This includes producers, primary manufacturers, secondary manufacturers, and consulting foresters. They survey every two years and gather contact information, listing of products and services, and the size and capacity of the business. New entrants into the industry are compiled from various sources, including current industry entitites and MSU Extension. That data is stored and available for industry’s use. The legacy Mi Wood system and public directory represent the Michigan Timber Industry to the public. The system requires updating in order to reduce maintenance costs, and deliver an ADA-compliant public website. The Mi Wood system will be included as a module within the Vegetative Management System (VMS). The VMS and Mi Wood projects will be run concurrently, resulting ins significant cost savings. Bringing Mi Wood into VMS will leverage existing VMS assets and technology and reduce redundant systems for user management via:

Shared firewall rules and maintenance configuration Shared user login and permissions system Linking the Online Bidding public portal to Mi Wood Online Bid public profile editing VMS Customers module to support customer management VMS Reports module to export data VMS Help module to provide training information Shared project management resources

PROJECT OBJECTIVE: The VMS Michigan Wood Module (VMS Mi Wood) will manage timber producer information and consumer data for presentation in a public facing directory integrated with the VMS Online Bid module. The business goal of the module is to maintain a current database of timber-related producers and provide a public industry directory representing the Michigan Timber Industry for strategic and economic purposes. There are two parts of the module: the public directory; and the internal directory management tool. The public directory is used by consumers as well as producers of timber services in Michigan. The internal management tool facilitates the surveying of updated company information on an annual basis as well as managing and publishing changes to the public directory and synchronizing VMS customer changes.

An n-tier approach will be used in this application, featuring a shared database and the internal application acting as a middle-tier for the public application so no direct database connection is needed from the public facing site. The framework will be Angular 2 over ASP.NET in C# to align with VMS project standards.

Completion of this VMS Mi Wood will maximize value for customers, improve ease of data collection and data entry, improve ease of data availability, and provide a modern, ADA-compliant web application. SCOPE OF WORK:

In Scope:

Requirements Validation and Release Planning o Analysis, Validation, and Creation of User Stories for Mi Wood functionality based on

information gathered during Joint Application Design (JAD) sessions with the user(s). o Product Backlog

Release Construction and Implementation (repeat per Sprint, per Release) o Sprint Planning

Analysis, Validation, and Verification of User Stories o Sprint Design, Construction and Testing

Functional Design Application Database Interface(s) Integration(s) Data dictionary System Design Application Database Interface(s) Integration(s) Architectural Assessment (EASA collaboration documentation) Security Assessment (DTMB 0710 collaboration and documentation) Test Plan Development Solution Application Solution Databases Solution Interfaces Solution Integrations Agile User Stories Agile Backlog Reports Agile Burn Down Agile Velocity

o Release Implementation Data conversion Data migration Configuration management Source code Development documentation/notes Change control

o Installation Instructions / procedures Implementation schedule Backup procedures Change control Installation acceptance testing Regression testing Backout / recovery plans and procedures

o Testing Unit Functional

Integration Verification Performance System and Standards User Acceptance Testing (UAT) Regression testing

o Training / Documentation End User Guides Administration Guides Technical Installation & Support Guides

Warranty o Warranty Period defect correction

Support and Maintenance o Continued Maintenance and Support for 5 additional year(s)

Out of Scope: Procurement or installation of hardware Procurement or installation of NAS / SAN disk Initialization or deployment of virtual servers Hosting services

TASKS: Technical support is required to assist with the following tasks: DELIVERABLES: Deliverables will not be considered complete until the Agency Project Manager has formally accepted them. Deliverables for this project include:

A. Public Directory

The main tenant in creating the public directory is usability. The directory must provide value to consumers as well as the timber industry; to do so it must be user friendly to search and use. This includes making the directory ADA compliant as well as responsive for mobile devices. Search The search functionality will be developed to be intuitive so that a user can search using natural language, including combining high level categories, geographic regions and keywords. A quick search will always be available at the top of the page. Browse The company directory can also be browsed alphabetically; both the search and browse page will use a common results page. From the results page a user can export the results to .CSV format or choose a company to view detailed information. Viewing a Company Detail When viewing a company detail, a user can see all public data that the company owner or administrator has allowed to be publically visible. The information will be organized in a section based view and will include an embedded map. The exact layout will be determined based on usability testing and analysis. Adding and Changing Company Information Anyone can propose to add a new company or make changes to core company details. Once the additions or changes are submitted they will be require approval in the internal site’s Change Queue at which point the changes will become published. Directory Export A PDF export of the public directory will be available for users who wish to download a printable version of the directory.

Public Stats A series of database wide statistics will be identified and pushed to the front end from the internal tool, up to four sections of statistics with optional graphs will be displayed. Details of the graphic components will be determined with the client during Joint Application Design sessions. Submitting a Survey When a survey is available to complete, a unique secure company link will be created and the survey that has been selected for the company can be filled out online. A link to the survey with a personal authentication key will be provided via e-mail or postal mail depending on the user’s notification preference.

B. Internal Management Application

The internal management application’s purpose is to maintain the public directory and to manage the survey process. Company Management Companies can be searched and browsed using equivalent functionality as is available on the public portal, however all changes will be made available in real time. Companies can also be added and deleted from this section. VMS Customer data will be automatically synchronized when changes are made and will be updated via the Change Queue. A viewable history of changes will be maintained. Changes will be logged in the history when company information is updated. Change Queue When unauthenticated changes are made on the public portal they will appear here to be approved by a moderator, a user can browse and view the requested changes with the differences highlighted for easy comparison. Once a change is approved it will be made available on the public portal. Survey Creation Simple free text or yes/no questions can be maintained and can be associated with one or many surveys. This allows for the ability to add simple questions to a survey type without code changes being necessary. Question building functionality will be designed to implement the surveys as currently designed; see Attachment A to this document for existing surveys. Survey design and implementation includes the ability to create questions, and the underlying data model required to deliver surveys and gather responses. Survey Batches A survey batch represents a group of survey requests that have been associated with a company or group of companies. A survey batch can be published to the public portal as well as a printable export for the mailing / printing center. Each request (either physical or e-mailed) will contain a link with a one-off authentication key that can be used to enter the survey results online. Manual survey responses can also be added from this section when paper or phone surveys are returned. Online Bid A link from online bid will be provided to go from the Online Bid portal to the customer detail and/or survey link if a survey is available. This link between the systems will help outreach for producers that may currently not be in the system. Directory Export A PDF export of the public directory will be available for users who wish to download a printable version of the directory.

C. Conversion Directory data will be converted from the previous SQL Server database for the initial population of the directory data. Loggers in the VMS database currently not in the MI Wood directory will also be converted. Survey data will not be converted as there are multiple MS Access databases available and the final format may require too much conversion from the various data types.

Key Activities and Deliverables:

Milestones Activities Cost 10%

Holdback Release Sprints

Product Backlog Grooming $6,710.00 $671.00

Sprint Planning $6,710.00 $671.00 Application Development $248,270.00 $24,827.00 Sprint Review $3,355.00 $336.00 Sprint Retrospective $3,355.00 $336.00 Development Deliverables

SEM-0302 Software Configuration Management Plan

$345.00 $35.00

SEM-0501 Functional Design $380.00 $38.00 SEM-0601 Conversion Plan $423.00 $42.00 SEM-0602 Test Plan $431.00 $43.00 SEM-0603 Test Type Approach and Report $431.00 $43.00 SEM-0604 System Design Document $1,344.00 $134.00 eMichigan Review $974.00 $97.00 Enterprise Architecture (EA) Assessment $436.00 $44.00 Project Security Plan and Assessment (DTMB-

0170/LockPath) $1,090.00 $109.00

Operations Plan $218.00 $22.00 Requirements Traceability Matrix $228.00 $23.00

Testing Installation and Configuration of QA Environment

$4,937.00 $494.00

User Acceptance Testing Execution $5,376.00 $538.00 Training SEM-0703 Training Plan $224.00 $22.00 Training Guides $672.00 $67.00 Training Execution $3,136.00 $314.00 Implementation SEM-0701 Transition Plan $774.00 $77.00 SEM-0702 Installation Plan $1,189.00 $119.00 Installation and Configuration of Product

Environment $1,792.00 $179.00

Total Cost $290,800.00 $29,080.00 ACCEPTANCE CRITERIA: All deliverables, including documents and software, are subject to the acceptance criteria as defined in the original contract. PROJECT CONTROL AND REPORTS: All project control and reports will be the same as that of the base contract terms. SPECIFIC DEPARTMENT STANDARDS: Agency standards, if any, in addition to DTMB standards. PROJECT SCHEDULE:

All requirements meetings, development sprints, quality assurance activities, and user acceptance testing will happen in concurrence with VMS 5.0. Work will begin on September 18, 2017 starting with two weeks of planning which will include writing requirements, completing the functional design, and building the product backlog. Development will occur in two phases. Phase I will be completed for release on July 26, 2018. Phase II will be completed as part of VMS 5.0 Release 3 on May 9, 2019. Note that the State of

Michigan is currently in the process of implementing SIGMA, a replacement system for MAIN. SIGMA is slated to be implemented in October, 2017. DTMB resource availability may be affected by the SIGMA project.

Release # Module Functionality Release Date MiWood Release 1

VMS 5 MiWood Module Phase I

Public Directory: Search Browse Viewing a Company

Detail Directory Export

Internal Management:

Company Management Survey Creation Online Bid Directory Export

Conversion

7/26/2018

MiWood Release 2 / VMS Release 3

VMS 5 MiWood Phase II

Public Directory: Adding and Changing

Company Information Public Stats Submitting a Survey

Internal Management:

Survey Batches Change Queue

5/9/2019

PAYMENT SCHEDULE: Payment will be made on a firm fixed price basis, including all post‐implementation, less identified holdbacks. Maintenance and support will be paid on Time and material basis in accordance with the rates provided in the base contract 071B4300022. All costs associated with future enhancements will be submitted in a contract change notice with a Statement of Work for a firm fixed price in accordance with the Contractor’s rate card. Payment will only be made upon successful completion and State’s formal acceptance of milestone items listed in this document and upon the agreed schedule as in the original contract Attachment B – Payment Schedule. Any work effort, outside of the Scope of this SOW will follow the Project Change Request approval process. DTMB will pay the Contractor upon receipt of properly completed invoices and supporting signed acceptance documents by DTMB and DNR. Invoices must be submitted to the billing address on the State issued purchase order not more often than monthly. All invoices should reflect actual work completed by invoice date, and must

be approved by the DTMB Project Manager prior to payment. DTMB Accounts Payable area will coordinate obtaining approval from the DTMB Project Manager, which will be provided only upon the completion of each release and the deliverables outlined for the release. The invoices shall describe and document to the State’s satisfaction and a description of the work performed and the progress of the project. All invoices must include the SOM issued purchase order number. Payment shall be considered timely if made by the DTMB within forty-five (45) days after receipt of properly completed invoices. Contractor will be required to remit an 1% Administrative Fee, per Section 2.031 of the Contract on all payments remitted under the Contract. EXPENSES: The State will NOT pay for any travel expenses, including hotel, mileage, meals, parking, etc. PROJECT CONTACTS: The designated Agency Project Manager is: Doug Heym Department of Natural Resources Forest Resources Division 525 W. Allegan, Constitution Hall Lansing, MI 517-284-5867 [email protected] The designated DTMB Project Manager is: Robin Krzciok Department of Technology, Management and Budget Enterprise Project Management Office 525 W. Allegan, Constitution Hall Lansing, MI 517-335-3211 [email protected] LOCATION OF WHERE THE WORK IS TO BE PERFORMED: Consultants will work at Constitution Hall in Lansing, Michigan. EXPECTED CONTRACTOR WORK HOURS AND CONDITIONS: Work hours are not to exceed eight (8) hours a day, forty (40) hours a week. Normal working hours of 8:00 am to 5:00 pm are to be observed unless otherwise agreed to in writing. No overtime will be permitted. This purchase order is a release from Contract Number 071B4300022. This purchase order, statement of work, and the terms and conditions of Contract Number 071B4300022 constitute the entire agreement between the State and the Contractor.





$5,779,738.37



December 31, 2019


3 - 1 Year


N/A





☐ ☐ December 31, 2019


N/A

$5,161,400.00 $10,941,138.37

Effective May 15, 2017, the attached Statement of Work for development of Vegetative Management System (VMS) phases 5.0, 6.0 and 7.0 and maintenacne and support of VMS phases 4.0, 5.0, 6.0 and 7.0 is incorporated into this Contract and is increased by $5,161,400.00. Please note that the Contractor Administrator has been changed to Malu Natarajan and Program Manager has been changed to David Gabler. All other terms, conditions, specifications, and pricing remain the same per Contractor proposal,Agency agreement, DTMB approval and State Administrative Board approval on 4/25/2017.

[email protected]

David Gabler

Malu Natarajan

[email protected]

John Leigh



*******1652

517-202-4625


(517) 284-7030

STATE

Pro

gra

m

Manager

Contra

ct

Adm

inistra

tor

CO

NTRACTO

R

DTMB-IT

517-284-4512


DTMB

N/A

DESCRIPTION

[email protected]

CONTRACT SUMMARY




Program Managers

for





STATEMENT OF WORK

Project Title: Vegetative Management System 5, 6, & 7 (VMS)

Period of Coverage:4/3/2017 – 5/1/2021

Requesting Department: Department of Natural Resources

Date: 3/29/17

Agency Project Manager: Doug Heym

Phone: 517-284-5867

DTMB Project Manager: N/A

Phone: N/A

Brief Description of Services to be provided: BACKGROUND: The Michigan Department of Natural Resources (DNR), Forest Resources Division (FRD) is responsible for

managing 3.9 million acres of state forest. Part of the management responsibilities of the state forest system

includes the identification of timber inventory, management of marketable timber resources, and all aspects of

the timber sale. Historically, timber sales affect over 60,000 acres of state forest annually with an average of

800,000 total cords per year and recent contract value averaging a total of $45 million a year.

To support these management responsibilities, over the past two decades the DNR has implemented a number of

systems and manual processes, to include tools to manage the marketable timber resources, tools to maintain the

acquisition source of the resources, and tools to manage timber sales and oversight of resulting contracts. During

their use, the tools have been maintained and modernized to leverage both GIS capabilities and updated

technology as well as integration with related data sources and systems. One such ongoing effort is the migration

between the original Timber Sale (T‐Sale) system for managing a timber sale, and the Vegetative Management

System (VMS).

T‐Sale and VMS are used by FRD to consume marketable timber resource information from an additional system

(Michigan Forest Inventory), develop a proposal, issue a proposal, elicit bids, award and manage all aspects of the

resulting contract to include payments, bonds, performance, and amendments.

PROJECT OBJECTIVE: The VMS system has been implemented in a series of phases to address changing needs in functionality, as well as

enhancements supported by more modern technology. “VMS 4” is the current phase in production and continues

to be used in parallel to functionality still only supported in T‐Sale. In preparation for continuing VMS phases, and

the decommissioning of T‐Sale, the DNR completed requirements and functional design activities for “VMS 5” in

2015, followed by requirements and functional design activities for “VMS 6” in 2016. “VMS 7” is included in this

scope, however, full requirements or functional specifications have not yet been done for the VMS 7 functionality.

A priority of the agency for VMS 5, 6, and 7 is to ensure that functionality developed is on a modern platform that

adheres to industry standards and is on the Microsoft roadmap for future architectures. .NET Core was

evaluated, however the framework is missing some key features, such as a complete Entity Framework

implementation with lazy loading. As such, the Contractor has chosen to use the same technology stack as the

Land Ownership Tracking System (LOTS) project, .NET MVC 4.6 (C#) and Angular 2. .NET Core (MVC 5). While we

cannot recommend .NET Core for the system architecture, what we have chosen is well situated for a conversion

to .NET Core later, if necessary.

To minimize disruption to business users, MDNR desires a modular approach that supports running the current

system (VMS 4 and T‐Sale) and new VMS 5, 6, and 7 in parallel, retiring functionality in T‐Sale as it becomes

available in the new VMS 5, 6, and 7. This approach also requires sharing data dynamically. The current

application data resides in the VMS Server Database (MSSQL), which will also be used by VMS 5, 6, and 7.

The high‐level scope of work for this project includes:

1. Designing and developing new, ADA‐compliant functionality for the Vegetative Management System (VMS) as

defined by the functional requirements specified in the VMS 5, 6 and 7 Statement of Work.

2. Completing data migration from the Timber Sale (T‐Sale) program to VMS in preparation for the

decommissioning of the T‐Sale system.

3. Enhancing the Online Bidding customer portal to support publishing correspondence, improving efficiency

and reducing costs related to customer correspondence.

4. Assuming maintenance and support of VMS 4, when VMS 5 is released.

Statement of Work

1.100 Scope of Work and Deliverables

1.101 IN SCOPE

This project consists of the following scope:

1. Transition‐In

Project Kick‐Off

Project Initiation

Project Charter

2. Requirements Validation and Release Planning

Analysis, Validation, and Creation of User Stories for VMS 5, VMS 6 and VMS 7 functionality

based on the previously completed definition documents (Attachments A, B and C)

Product Backlog

3. Release Construction and Implementation (repeat per Release)

a. Sprint (repeat per Sprint within the Release)

Sprint Planning

o Analysis, Validation, and Verification of User Stories

Sprint Design, Construction and Testing

o Functional Design

o Application

o Database

o Interface(s)

o Integration(s)

o Data dictionary

o System Design

o Application

o Database

o Interface(s)

o Integration(s)

o Architectural Assessment (EASA collaboration documentation)

o Security Assessment (DTMB 0710 collaboration and documentation)

o Test Plan

o Development

o Solution Application

o Solution Databases

o Solution Interfaces

o Solution Integrations

o Agile User Stories

o Agile Backlog Reports

o Agile Burn Down

o Agile Velocity

b. Release Implementation

Implementation

o Data conversion

o Data migration

o Configuration management

o Source code

o Development documentation/notes

o Change control

Installation

o Instructions / procedures

o Implementation schedule

o Backup procedures

o Change control

o Installation acceptance testing

o Regression testing

o Backout / recovery plans and procedures

Testing

o Unit

o Functional

o Integration

o Verification

o Performance

o System and Standards

o User Acceptance Testing (UAT)

o Regression testing

Training / Documentation

o End User Guides

o Administration Guides

o Technical Installation & Support Guides

4. Warranty

Warranty Period defect correction

5. Support and Maintenance

Continued Maintenance and Support for 5 additional year(s)

6. Future Enhancements

1.102 OUT OF SCOPE

Procurement or installation of hardware

Procurement or installation of NAS / SAN disk

Initialization or deployment of virtual servers

Hosting services

1.103 ENVIRONMENT

The links below provide information on the State’s Enterprise Information Technology (IT) policies,

standards and procedures which includes security policy and procedures, eMichigan web development,

and the State Unified Information Technology Environment (SUITE).

Contractors are advised that the State has methods, policies, standards and procedures that have been

developed over the years. Contractors are expected to provide proposals that conform to State IT

policies and standards. All services and products provided as a result of this RFP must comply with all

applicable State IT policies and standards. Contractor is required to review all applicable links provided

below and state compliance in their response.

Enterprise IT Policies, Standards and Procedures:

http://michigan.gov/dtmb/0,4568,7‐150‐56355_56579_56755‐‐‐,00.html

All software and hardware items provided by the Contractor must run on and be compatible with the

SOM DTMB Standard Information Technology Environment. Additionally, the State must be able to

maintain software and other items produced as the result of the Contract. Therefore, non‐standard

development tools may not be used unless approved by SOM DTMB. The Contractor must request, in

writing, approval to use non‐standard software development tools, providing justification for the

requested change and all costs associated with any change. The SOM DTMB Program Coordinator must

approve any tools, in writing, before use on any information technology project.

It is recognized that technology changes rapidly. The Contractor may request, in writing, a change in the

standard environment, providing justification for the requested change and all costs associated with any

change. The State’s Program Coordinator must approve any changes in writing, along with SOM DTMB,

before work may proceed based on the changed environment.

Enterprise IT Security Policy and Procedures:

http://www.michigan.gov/documents/dmb/1210.32.pdf

http://www.michigan.gov/documents/dmb/1335_193161_7.pdf

http://www.michigan.gov/documents/dmb/1340_193162_7.pdf

The State’s security environment includes:

SOM DTMB Single Login

SOM DTMB provided SQL security database

Secured Socket Layers

SecureID (State Security Standard for external network access and high risk Web systems)

SOM DTMB requires that its single login security environment be used for all new client‐server software

development. Where software is being converted from an existing package, or a client‐server

application is being purchased, the security mechanism must be approved in writing by the State’s

Program Coordinator and SOM DTMB Office of Enterprise Security.

Any additional Agency specific security requirements above and beyond the enterprise requirements

and standard terms and conditions stated in the Professional Services Terms and Conditions document

must be provided as part of the Agency Specific Technical Environment.

Technology Components:

Look and Feel Standard:

All software items provided by the Contractor must adhere to the Look and Feel Standards

www.michigan.gov/somlookandfeelstandards.

ADA Compliance:

The State is required to comply with the Americans with Disabilities Act of 1990 (ADA), and has adopted

a formal policy regarding accessibility requirements for websites and software applications. The State is

requiring that Contractor’s solution conform, where relevant, to level AA of the World Wide Web

Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0. Contractor may provide a

description of conformance with the above mentioned specifications by means of a completed

Voluntary Product Accessibility Template for WCAG 2.0 (WCAG 2.0 VPAT) or other comparable

document. Contractor may consider, where relevant, the W3C’s Guidance on Applying WCAG 2.0 to

Non‐Web Information and Communications Technologies (WCAG2ICT) for non‐web software and

content. Any additional compliance requirements shall be specified in the Statement of Work.

State Unified Information Technology Environment (SUITE):

In managing its obligation to meet the above milestones and deliverables, the Contractor is required to

utilize the applicable State Unified Information Technology Environment (SUITE) methodologies, or an

equivalent methodology proposed by the Contractor. Contractor is required to review

http://www.michigan.gov/suite and demonstrate how each PMM/SEM step/document will be

completed. If the contractor desires to use their own documents, the Contractor must submit an

example of the document that will be substituted. If the contractor deems a document as non‐

applicable, Contractor must provide reasons for the determination. The State reserves the right to give

final approval of substituted documents and items marked as non‐applicable.

SUITE’s primary goal is the delivery of on‐time, on‐budget, quality systems that meet customer

expectations. SUITE is based on industry best practices, including the Project Management Institute’s

PMBoK and the Capability Maturity Model Integration for Development. It was designed and

implemented to standardize methodologies, processes, procedures, training, and tools for project

management and systems development lifecycle management. It offers guidance for efficient, effective

improvement across multiple process disciplines in the organization, improvements to best practices

incorporated from earlier models, and a common, integrated vision of improvement for all project and

system related elements.

While applying the SUITE framework through its methodologies is required, SUITE was not designed to

add layers of complexity to project execution. There should be no additional costs to any vendor, since it

is expected that they are already following the similar industry best practices that form SUITE’s

foundation.

SUITE’s companion templates are used to document project progress or deliverables. In some cases,

vendors may have in place their own set of templates for similar use. Because SUITE can be tailored to

fit specific projects, project teams and State project managers may decide to use vendor provided

templates, as long as they demonstrate fulfillment of the SUITE methodologies.

Agency Specific Technical Environment

The Solution should be hosted on the State’s Next Generation Digital Infrastructure (NGDI). All NGDI

servers will be virtual servers. The Solution must be compatible with virtualization, X86‐compatible, and

deploy on State‐owned SAN or NAS storage solutions. OS must be Windows 2012 or higher (IIS 8.0 or

higher). The Solution should run on a hardware load‐balanced, virtual server environment.

Hardware Architecture

The State hosts a standard set of Production (PROD), Quality Assurance (QA), and Development (DEV)

servers. Only State administrators have direct access to the PROD and QA servers. State application

developers and vendors can have direct access to the DEV servers for testing, troubleshooting of

applications, and patching.

Any necessary custom code for the Solution should adhere to the following Application Development

standards:

Application Development Environment Standards (New applications and vendor)

Framework ‐ .NET 4.5 or higher

Web Application Development Framework ‐ ASP.NET 4 or higher

Programming Languages ‐ C#.NET

Integrated Development Environment (IDE) – Visual Studio 2013 or higher

Internet Information Services (IIS) – IIS 8.0 or higher

Supported Web Browsers – IE10* or higher, Chrome, Firefox, Safari

Supported Database ‐ SQL Server 2008 or higher

Version control – 2013 Team Foundation Server (TFS)

Reporting – Visual Studio local reporting (RDLC,RDL), 2008 SQL Server Reporting Services (SSRS)

or higher

Object Notation – XML, JSON

Native Mobile – PhoneGap

Web ‐ HTML5, CSS3, jQuery, Ajax, JavaScript, AngularJS, Bootstrap, LESS

Query Languages – T‐SQL, Linq

GIS – ESRI ArcGIS current version

Third Party Tools – Only authorized items

Debugging Tools ‐ Fiddler

Coding methods and best practices – Approved guidelines for this area

Application Development Testing Tool Standards

QUnit

Jasmine

ADA compliance software – JAWS 13 or higher

Proposals built around a COTS framework must identify the technology solutions that address the above

requirement categories (i.e. Framework, programming languages, integrated development environment

etc.). *If required per project reference backward compatibility to eMichigan standards.

Look and feel standards specific to VMS are in Attachment D.

A system interaction diagram specific to VMS is in Attachment E. Note that the State of Michigan is

currently in the process of implementing SIGMA, a replacement system for MAIN. Requirements and

specification efforts for VMS 6 were completed with the assumption that SIGMA would be implemented

by October 2017 and available for VMS to interface to (via the Michigan Cashiering and Receivable

System, MiCaRS). An initial draft of the VMS to MiCaRS interface specification document is in

Attachment F.

Contractor will continue to use stored procedures for VMS functions involving accessing data from more

than one of the VMS data tables.

1.104 WORK AND DELIVERABLES

The Contractor must provide Deliverables/Services and staff, and otherwise do all things necessary for

or incidental to the performance of work, as set forth in the Statement of Work and any Attachments.

The following section includes the work and deliverables that the Contractor will be required to perform

and / or submit during the contract term.

The development of the VMS Solution must agree with the standards set forth in 1.103 Environment.

In the event that code development is hosted by the Contractor, the Contractor will perform the initial

installation and configuration into the State’s Development servers on site.

The project will utilize the SUITE standards for project management, associated forms, and templates.

All forms and templates referenced below (e.g., PMM‐0102, SEM‐0402, etc.) may be found at the SUITE

link in 1.103 Environment.

Contractor shall use an Agile process and shall tailor the project using the State’s “Agile Process Guide”.

The VMS 5, VMS 6, and VMS 7 definition documents in Attachments A, B and C will be used to create the

Product Backlog.

Every Agile sprint cycle will conclude with the Sprint release code being applied to the State

Development servers. The sprint review (AKA “Show and Tell”, “the Demo”) will be conducted in

the State Development environment. The Contractor will provide all the documentation required to

complete this task which includes but is not limited to test scripts and user manuals.

In the event that Agile “Stand Up”, “Scrum of Scrums”, other meeting sessions will be conducted

virtually, the Contractor shall describe the tools and technology to be used. The costs associated

with hosting virtual sessions will be the responsibility of the Contractor.

Release schedule: The Contractor shall provide 8 production releases grouped by functionality at the

release dates provided below.

Release # Module Functionality Release Date

Release 1 VMS 5

Prerequisite Activities

9/7/2018

System Maintenance

Dashboard

Award Contact Search

Manage Customer

Manage Contract

Bond

Release 2 VMS 5 Manage Amendment 1/15/2019

Release 3 VMS 5 Reporting 3/28/2019

Release 4 VMS 5 Annual Progress Report 7/15/2019

Release 5 VMS 6 Manage Contract (Receipt Related) 4/6/2020

1.104.I Business Need Overview

1.104.I.A Current State

Timber Sales

Inventory information is maintained in the Michigan Forest Inventory (MiFI) system. MiFI is a GIS‐based system. Inventory information includes the land location, vegetation details, and the determined treatment for the ongoing use and management of land and its associated vegetation.

Land acquisition information is maintained in the Michigan Land Ownership Tracking System (LOTS).

Acquisition information is used to determine the financial accounting codes appropriate for revenue

associated with timber sale and land use.

A SharePoint site is used to stage Cruise information related to a sale. Data files are manually

named in the SharePoint file location (usually with the associated sale number). VMS includes

functionality to prompt for the file name and import the associated data file when developing a

Proposal.

VMS publishes a number of standard reports to a SharePoint site for both internal and public access.

VMS consumes treatment area information from MiFI to support the development of a timber sale

proposal. DNR FRD staff develop a proposal for the sale in VMS. A number of business rules and

policies, including a review and approval process, are part of the VMS “Proposal Module”. Once a

proposal is finalized, the related prospectus is published to www.michigan.gov/timberbidding, a

public facing web application for bidders to submit bids. Once the bidding submission period is

concluded, a bidder is selected and the contract awarded.

Manage Customer (Receipt Related)

Deposits

Manage Contract (Receivable Related)

Manage Customer (Receivable Related)

Manage Amendment Changes (Admin Amend)

Bond Updates

Release 6 VMS 6

Reports

6/2/2020 Fuelwood Permit

SSIS Packages

Release 7 VMS 6 Timber Permits 8/19/2020

Release 8 VMS 7

Customer Portal

3/4/2021

Amendment Changes (VMS 7)

Manage Contract

Proposal

Reports

Field Inspection Mobile App

Arc Map Customization

o A single Proposal can contain multiple Payment Units (PU).

o A single PU can consist of one or more species and products of timber.

o A single PU can consist of one or more individual land parcels.

o A single land parcel can have one or more acquisition sources.

A standard checklist of tasks related to the development of a proposal are done manually and

recorded on a standard MS Word Template.

The map used to accompany a proposal is in most cases manually created via tools external to

VMS and attached to the proposal as a separate document. There is no systematic integration

between a GIS‐based system and the proposal for the inclusion of the sale map.

The VMS to T‐Sale integration exchanges prospectus and bid information with T‐Sale. T‐Sale

interfaces with LOTS to associate the acquisition information to the PUs on the sale.

T‐Sale receipts all monies associated with the sale (as well as for other types of items being paid

for at the DNR FRD field offices).

All correspondence and contract related documents are published and distributed in paper

format.

Past due monies and outstanding actions are manually tracked.

Timber sales require a bond.

Timber sales can have one or more amendments (date extension, change in volume or acres,

split PU, etc.)

Inspections of a timber sale during harvest and at completion of harvest and contract expiration

are manually completed and recorded.

Bonds

Bonds can be cash, surety, letter of credit or CD.

Bonds can be specific to single sale or permitted event, Statewide for timber sales, Statewide for

permitted events, or Statewide for multi‐use.

TSale is used to receipt the collection of cash bonds.

A stand‐alone MS Access application is used to track the collection, use, and refunding of all

bonds.

Fuelwood Permits

Fuelwood Permits are traditionally available on an annual basis, starting in April, based on

department policies.

Although the process supports the option to complete and submit an application form, most are

purchased directly from a DNR field office.

Fuelwood permits are a fixed cost, do not require a bond, define the area for fuelwood

collection, and are issued to an individual based on eligibility.

The issued permit is a hand written two part form, with one part being given to the recipient,

and other kept by the DNR office.

There are multiple approaches in use by the DNR offices to define and record the area of

collection.

Fuelwood Permit purchases are receipted in TSale, or for offices with the Retail Sales System

(RSS), in RSS.

Event/Use Permits

Event /Use Permits can be for a single use of State land, or ongoing use of State land.

Event permits are requested with the use of an application. There is a fixed application fee for

all types of event/use permits.

Depending on the type of event/use, an application review fee may be charged. The fee is

determined by the estimated effort needed to complete the review.

If the permit is granted, there can also be a single Timber Consideration Fee (TCF) charged for

the permit, as well as a monitoring and use fee for each year of the permit (single use would be

charged once, multiple year would be charged for each year).

The issued printed permit is based on an MS Word template.

Tracking of event/use permits is done manually.

Fees for permit applications, application review, TCF, use and monitoring is receipted in TSale.

Small Receipt Sale (will be known as a Timber Permit in future state)

A small receipt sale is similar to a timber sale, but limited in value and does not require a bidding

process for award.

A small receipt sale includes sale conditions.

A small receipt sale may or may not require a bond.

T‐Sale is used to create the small receipt sale.

T‐Sale is used to receipt monies collected for the small receipt sale.

Deposits

In accordance with DNR policies, each DNR office is assigned a unique bank branch for

conducting their banking. Each bank branch in use throughout the State is assigned a unique 4‐

digit number. This number is used to reconcile deposit information.

Treasury works with each of the banks to order printed bank deposit slips and distributes them

to each of the DNR offices. The slips include the bank account number in use by the State and

the 4‐digit unique number assigned to that office for use.

Each DNR office manually prepares a bank deposit slip to list each check separate, and a total of

the cash to be deposited.

Referencing the associated information in T‐Sale, the field staff manually prepares a deposit fax

cover sheet with the accounting codes for the State distribution of deposited funds. Additional

information included with the cover sheet includes a copy of the bank deposit ticket. This

information is manually faxed to the DNR Cashier’s Office. The Cashier’s Office staff monitor for

the associated deposit on bank statements and manually moves deposited funds to the

indicated accounts on the deposit fax cover sheet.

In parallel to VMS 6 requirements, DNR is piloting a remote check scanning solution in one of its

offices. This process is similar to working with the local bank branch, however, the deposit

ticket provided by Treasury is unique to the bank supporting the remote check scanning solution

and is included as the first item scanned by the office. The field staff complete and submit the

fax deposit cover sheet and supporting information the same way as if the checks were

deposited at a local bank branch.

Performance Issues

DNR FRD maintains information in VMS related to performance issues incurred during the

execution of a contract or permit. Performance issues are tracked in VMS associated with an

individual and evaluated for eligibility for bidding, permits, and acceptance of payments via

personal check.

Reports

DNR FRD maintains a number of queries used to extract data from both VMS and TSale to

support the creation of standard reports. Most of the reports are formatted tables using MS

Excel, requiring the query results to be manually imported in MS Excel, calculations applied, and

formatted for publication. Report content includes financial reconciliation (monthly and

annually); monthly and year to date summaries of timber sales, permits and related financials;

and year end reports.

1.104.I.B Future State

Timber Sales

Add functionality to VMS to obtain the land acquisition information from LOTS for PU on a

contract.

Add functionality to VMS for the workflow management to complete items on the proposal

checklist.

Add functionality to VMS for the systematic creation and inclusion of the sale map with

proposal.

Add functionality to VMS to finalize a contract based on the winning bid and existing proposal.

Add functionality to VMS to manage the contract through its execution, to include amendments.

Add functionality to VMS for the inclusion of an inspection module to allow for the management

of inspections and collection of inspection related data, to include photos and field notes.

Add functionality to VMS to receipt payment for contract items.

Add functionality to VMS to generate receivables related to invoices.

Add functionality to VMS to close a contract.

Add functionality to VMS to provide Michigan Cashiering and Receivables System (MiCaRS)

accounting information for reallocation of payments to contract payment items.

Bonds

Add functionality to VMS to receipt cash bonds.

Add functionality to VMS to track bonds and bond allocation.

Add functionality to VMS to provide MiCaRS accounting information for receipt and reallocation

of bonds.

Fuelwood Permits

Add functionality to VMS for the creation and issue of fuelwood permits.

Add functionality to support using a scanner to read the magnetic strip on a Michigan ID or

drivers license for the number, name, and address information.

Add functionality to VMS for the receipting of payment for fuelwood permits.

Add functionality to VMS to record when fuelwood permit fees are made using RSS.

Event/Use Permits

Add functionality to VMS to create payment items associated with a permit.

Add functionality to VMS to receipt payment for permit items.

Add functionality to VMS to provide MiCaRS accounting information for receipt of permit fees.

Add functionality to VMS to systematically generate invoices and associated receivables for

multi‐use permits.

Small Receipt Sale (will be known as a Timber Permit in future state)

Add functionality to VMS to create a Timber Permit, to include review and approval of the sale.

Add functionality to VMS to obtain the land acquisition information from LOTS for the parcels

involved in the permit.

Add functionality to VMS for the receipting of payment for timber permits.

Add functionality to VMS to provide MiCaRS accounting information for receipt and reallocation

of payments associated with Timber Permits.

Deposits

Add functionality to VMS to manage received payments and track their deposit status.

Add functionality to VMS to create the bank specific deposit slip for payments not yet deposited.

Add functionality to VMS to maintain the acquisition codes and amounts associated with each

receipted payment.

Add functionality to VMS to provide MiCaRS accounting information for deposited payments.

Reports

Add functionality to VMS to include the reports manually created using data extracts. Include

search and filter fields to customize the result set represented on the report.

Add functionality to VMS to include the used reports still being ran from TSale.

Receipting

Add functionality to VMS to receipt for non‐timber and permit related items.

Add functionality to VMS to provide MiCaRS accounting information for receipting for non‐

timber and permit related items.

Receivables

Add functionality to VMS to query MiCaRS for the status of invoices and update related invoice

items based on the invoice payment status.

VMS Dashboard

Add functionality to VMS to display a dashboard view of items in need of action or awareness

based on the user related to contracts, permits and invoices.

Customer Portal

Add functionality to VMS to allow customers to receive documents, letters and published forms

to a secure web portal.

1.104.II Transition-In

Immediately following contract orientation, the Contractor shall complete Initiation and planning

activities in accordance with the SUITE Project Management Methodology (PMM), to include the

completion of the Project Charter (PMM‐0101) and Project Plan (PMM‐0102). The State expects the

Project Charter and Project Plan deliverables to be accepted within two (2) weeks of Contract Execution.

The Project Plan must define deliverables and tools being used to adhere to SUITE and the SUITE Agile

Process Guide.

In parallel, the Contractor shall initiate Transition‐In activities and documents to successfully provide

development and integration services in support of the solution. The State expects Transition‐In to

represent tasks and activities that can be completed within one (1) month of Contract Execution. The

Transition‐In Plan shall define the roles, responsibilities, tasks, resources, effort and dependencies for

the Contractor to successfully transition in, initiate the project and begin providing development and

integration services. Transition‐In Plan shall be approved by the State prior to plan execution.

As part of the Transition‐in Plan activities, the Contractor will complete and/or update applicable SUITE

documentation:

Project Charter (PMM‐0101)

Project Plan (PMM‐0102)

Enterprise Architecture Software Assessment (EASA). The State will be available to advise the

Contractor with the completion of this document.

Project Schedule

DTMB Security Plan and Assessment (DTMB 0170) or LockPath

Deliverable(s)

Project Charter (PMM‐0101)

Project Plan (PMM‐0102)

Project Schedule

Enterprise Architecture Solution Assessment (EASA)

Operations Plan

Security Plan and Assessment (DTMB 0170) or LockPath

Acceptance Criteria

High‐level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section

1.500 Acceptance. Additional or more specific acceptance criteria are listed below:

Deliverable Specific Acceptance Criteria

Project Charter Charter clearly defines the Goals and Business Needs being met by the project

Charter clearly describes the project

Charter clearly defines measurable project objectives

Charter clearly defines scope (in and out of scope items)

Charter includes initial estimates for resource usage, budget, and schedule dates


Charter defines the project approval authority and oversight committee

Plan clearly facilitates the initiation of the project

Plan clearly defines one‐time activities that allow the Contractor to assimilate into the State facilities, network and software development environment

Plan clearly defines workspace requirements

Plan clearly defines access to workspaces

Plan clearly defines access to technical environment

Plan clearly defines project document file structure

Plan clearly defines file sharing capabilities

Plan clearly defines connectivity capabilities

Plan is understandable, reasonable and accounts for all related tasks and resources (staff, equipment, tools, etc.)

Plan addresses State work schedule and resource schedules

Project Plan Plan includes the project statement of work

Plan clearly defines the deliverables and tools being used to comply with SUITE and the SUITE Agile Process Guide

Plan clearly defines the review and approval roles for each deliverable

Plan includes the overall project approach

Plan defines the project critical success factors

Plan includes a detailed project schedule and high‐level milestones

Plan clearly defines the roles and responsibilities for the immediate project team and stakeholders

Plan includes a detailed project budget to include budget by role, function, and milestone

Plan includes communications plan for the project

Plan includes change management plan for the project

Plan includes quality management plan for the project

Plan includes risk management plan for the project

Plan includes issue management plan for the project

EASA Plan clearly defines the impact of the solution on existing architecture, technology standards, programming environment, database management system (and version number), operating systems (including versions) and hardware


Plan clearly defines any approach deemed necessary for conformance, upgrade or modifications to the existing State enterprise architecture or software environment

Project Schedule Schedule clearly defines milestones and expected completion dates

Schedule clearly defines work breakdown structure

Schedule clearly defines tasks, durations and resources

Schedule clearly defines critical paths

Security Plan and Assessment (DTMB 170) or LockPath

Plan clearly defines the solution’s security requirements and the controls necessary to provide protection against its risks and vulnerabilities

1.104.III Requirements Validation and Release Planning

No later than the completion of the Transition‐In activities, the Contractor will initiate requirements

validation activities to include creation of the Agile Product Backlog and release planning for the

remainder of the project. Existing definition for VMS 5, 6 and 7 are in Attachments A, B and C.

The Contractor will complete multiple Sprints within each Release, adhering to the State’s Agile Process

Guide.

As part of Requirements Validation and Release Planning, the Contractor will develop and deliver Epics

and User Stories reflecting any identified updates confirmed by the validation. Any gaps in the

requirements will be identified and remedied by adding new requirements. The Contractor will use the

existing functional specification and definition documents to create the Agile Product Backlog and

Definition of Scope for each planned release.

As a baseline for each Sprint and support of the releases, the Contractor will deliver a Maintenance Plan

(SEM‐0301), Software Configuration Management Plan (SEM‐0302) and a Requirements Traceability

Matrix (SEM‐0401). The Contractor will update these, and other deliverables for each Sprint and

Release as applicable.

Deliverable(s)

Agile Product Backlog (for all Releases)

Definition of Scope (per Release)

SEM0301 – Maintenance Plan (initial)

SEM0302 – Software Configuration Management Plan (initial)

Epics & User Stories ‐ Analysis, Validation, and Creation of User Stories.

Acceptance Criteria




Agile Product Backlog Agile Product Backlog items are clearly supported by an Epic or user story

Epic could be a feature, customer request or business requirement. In backlog, it is a placeholder for a required feature with few lines of description. It tells compactly about final output of user needs.

User stories clearly define the 'who', 'what' and 'why' of each requirement

User stories clearly define what a user needs to be able to do

Agile Product Backlog items have clearly defined acceptance criteria (i.e., how the system should respond to user actions)

Agile Product Backlog items clearly have a business value/priority

Agile Product Backlog clearly covers the scope of functionality for VMS 5, 6 and 7.

Hardware Procurement Plan Plan clearly defines the hardware specifications

Plan clearly estimates the cost of the hardware

Plan clearly schedules procurement activities and product selection

Scope Statement (per Release)

Scope Statement clearly states backlog items to be included in each Release

Scope Statement clearly represents one and only one Release

Scope Statement clearly defines the scope of each Release in terms of the Agile Product Backlog

Scope Statements collectively for all Releases cover all Agile Product Backlog Items

There is a Scope Statement for each Release in the Contract


SEM‐0301 – Maintenance Plan (initial)

Plan clearly identifies the scope of maintenance efforts

Plan clearly identifies the processes and tools of the maintenance effort

Plan clearly quantifies staff and resources for maintenance efforts

Plan clearly provides the overall flow of work within the maintenance process

SEM‐0302 – Software Configuration Management Plan (initial)

Plan clearly identifies what software components are configuration items

Plan clearly identifies which configuration items will be tracked

Plan clearly defines the statuses that will be used to track the configuration items

Plan clearly addresses activities that are platform independent, such as identifying ‘configuration items’ (i.e., the items that will be placed under configuration management and defining roles and responsibilities, approval authority, repositories, process workflow, standard policy and audit procedures).

Plan clearly defines the process for managing work products throughout development, testing implementation and into the maintenance and support phase

User Stories Stories are clearly stated as business needs

Stories are clearly stated with unique objectives

Stores are clearly grouped by release

1.104.IV Release Construction and Implementation (repeat per Release)

1.104.IV.A Sprint (repeat per sprint within the release)

1.104.IV.A.i Sprint Planning

For each Sprint, the Contractor will complete Sprint Planning to define the Agile Product Backlog items

and related tasks to be included in the Sprint. The Contractor needs to consider impact to initial

versions of SUITE project documents, as well as both Release and Sprint specific deliverables and

documentation.

Deliverable(s)

Hardware Procurement Selection (dependent on Sprint scope)

Sprint Backlog

Tasks

Acceptance Criteria




Hardware Procurement Selection (depending on Sprint scope)

Selection clearly states hardware acquisition for the Sprint

Selection clearly states the final cost breakdown of the hardware acquisition

Selection clearly defines the hardware installation procedure

Selection clearly considers environmental factors (i.e., air conditioning, power supply, security, etc.)

Sprint Backlog The Backlog identifies items from the Agile Product Backlog to be included in the Sprint

Tasks The Tasks clearly decompose the Sprint Backlog items into smaller tasks.

1.104.IV.A.ii Sprint Design, Construction and Testing

Following the Sprint Planning activities for a Sprint, the Contractor will complete design, construction

and testing activities for the Sprint.

The Contractor will account for completion of Sprint specific deliverables, as well as appropriate updates

to release and project‐based deliverables impacted by the scope of the Sprint. The Contractor will

adhere to the State’s Agile Process Guide.

Sprint review and acceptance will include all Sprint related documentation, updates and deliverables

deliverables, as applicable to user stories in that Sprint and further defined in the accepted Project Plan

deliverable (PM‐0102). The accepted Project Plan will define how each of the following items are

addressed within each sprint, with the consideration of efficient and meaningful use of resources in

mind.

Deliverable(s)

Updated SEM‐0302 Software Configuration Management Plan

Updated SEM‐0402 or Product Backlog

SEM‐0501 Functional Design or Prototype / Wireframe

SEM‐0601 Conversion Plan (initial)

SEM‐0602 Test Plan

SEM‐0603 Test Type Approach and Report

SEM‐0604 System Design Document

SEM‐0606 Test Cases

Acceptance Criteria




SEM‐0302 Software Configuration Management Plan (updated per Sprint)

Plan clearly defines the configuration items

Plan clearly identifies the status of each configuration item

SEM‐0402 Requirements Specifications or Product Backlog (updated per Sprint)

Requirements are clearly stated as business needs

Requirements are clearly stated as a unique objective

Requirements gaps are identified and filled

Requirements maintain relationship to user story (ies)

Requirements clearly state the performance levels for newly acquired hardware (dependent on Sprint scope)

SEM‐0401 Requirements Traceability Matrix

Requirements are clearly stated and traceable from test cases to user stories to original requirements for all work that is completed during each release cycle.

Document must be produced at end of each sprint for traceability purposes

SEM‐0501 Functional Design Functional Design clearly describes detailed functionality

Functional Design clearly defines how functionality will be incorporated into the design

Functional Design clearly embodies all of the items in the Sprint Backlog


SEM‐0601 Conversion Plan Plan clearly defines the data conversion procedures

Plan clearly specifies new and converted files/databases

Plan clearly coordinates the file‐conversion and data implementation procedures

SEM‐0602 Test Plan Plan clearly defines how test scenarios will be tracked, monitored, and approved

Plan clearly defines how the requirements trace‐ability matrix will be used to ensure all functionality is tested

Plan clearly defines how defects are handled

Plan clearly includes functionality, hardware, interfaces, integration, and installation.

SEM‐0603 Test Type Approach and Report

Approach and Report clearly identifies all testing activities (e.g., tester training, environment setup, data setup, documentation setup, execution and reporting)

Approach and Report clearly identifies criteria for successful completion

Approach and Report clearly documents all test scenarios executed as expected and approved or defects reported

Approach and Report clearly communicates defects as reported, logged, mitigated or resolved

Approach and Report clearly reports and covers all test types (e.g., Unit, Integration, Functional, System/Standards, Performance, User Acceptance and Hardware)


SEM‐0604 System Design Document System Design clearly defines how the functional design will be incorporated into the technical solution

System Design clearly defines mock‐ups of all screens and identifies screen functionality

System Design clearly defines the Conceptual Data Model with all major entities and the relationships between them

System Design clearly defines business rules and calculations identified by data elements and tables

System Design clearly defines system‐generated reports and queries with all business rules and calculations identified by data element and table

System Design clearly defines interfaces, integrations and all data flows to and from the solution

System Design clearly defines communication protocols

System Design clearly defines file formats, web services or other forms of communication

System Design clearly accounts for each major action that must be performed and each data object to be managed.

System Design clearly accounts for each data object to be managed.

System Design clearly details each function such that a developer will be able to code.

Contractor’s Approach to Sprint Design, Construction and Testing:

Contractor’s development team will run two week sprints, in which all phases of the software

development lifecycle are executed for a specified body of work. Contractor will deliver four formal

releases for VMS 5, three for VMS 6, and one for VMS 7, totally eight releases.

After Product Backlog grooming and sprint planning are completed, development will begin. During the

sprint, the selected user stories will be:

Developed;

Tested internally by Contractor’s BA/Test Analysts;

Demonstrated to business users and project stakeholders for feedback and, if necessary, revised; and

Promoted to the QA environment for user acceptance testing (UAT).

While development is progressing, Contractor’s Test Manager and BAs will perform functional, system

integration, and regression testing and they will create user acceptance testing (UAT) test cases. At the

end of each sprint, the BAs will facilitate a UAT cycle with identified DNR resources. Any defects,

resulting from a code failure or a failure to meet requirements, found during UAT will be prioritized for

correction in an upcoming sprint. There will be four sprints per release, which may vary depending upon

DNR’s needs.

Toward the end of each two‐week sprint, Contractor will demonstrate the new or updated functionality

to identified DNR stakeholders. Feedback will be mutually evaluated to determine when it should be

acted upon. Feedback that expands user story scope may require change control or the addition of a

new user story.

At the end of each two‐week sprint, after the product demonstration, the sprint code that is developed

in the Contractor’s development environment, will be promoted to the State of Michigan (SOM) Sprint

UAT environment. While DNR users are testing a given sprint, the development team will be working on

the next sprint. Any issues found during sprint UAT will be documented and prioritized for inclusion in a

future sprint planning session;

After the fourth sprint is pushed to UAT, the development team will take 5 days to fix any outstanding

defects from sprints 1‐3, and build the official UAT release. Defects found in sprint 4 UAT will be fixed

during the 15‐day, formal UAT cycle, in which all functionality is tested for final acceptance. Since all

functions developed over the preceding sprints are tested again, this formal user acceptance testing also

acts as a regression test, ensuring proper functioning of all code developed over the previous sprints.

During this 15‐day Release UAT cycle, defects are repaired and re‐tested immediately. DNR will review

and approve UAT and once UAT is approved, Contractor will work with DTMB to promote the code to

the Production environment, within 30 days.

Contractor will work with eMichigan throughout the release cycle to ensure system designs are

compliant with eMichigan look and feel standards and ADA standards. Contractor will facilitate

eMichigan audit and approval during the 15‐day Release UAT cycle.

Deliverable Comment Form (DCF)

In order to capture and track review comments, the responses to the review comments, and the

resolutions for accepted comments, the Contractor will use the Deliverable Comment Form (DCF).

1.104.IV.B Release Implementation

At the completion and acceptance of the final Sprint in a release, the Contractor will complete

deliverables and activities related to the release, to include appropriate testing, training,

implementation and transition to support and maintenance.

The Contractor will be responsible for all aspects of training with the exception of providing hard copies

of the training materials and one support trainer to aid the primary trainer in questions and answers.

The contractor’s training responsibilities will include development and provision of training materials,

working with the SOM for provisioning of SOM training facilities, delivery of training, and post‐training

validation of content understanding.

Contractor will assign a Testing and Training Manager who will be responsible for:

Effectively leading training resources;

Developing a comprehensive training plan;

Ensuring training materials are updated with each sprint;

Working with the SOM to provision SOM training facilities and resources; and

Ensuring classes are conducted on time, and to the satisfaction of DNR.

End user and administrator training will be combined into one course and will be delivered after each

release to cover the functionality developed for that release. Priliminary planning includes:

Two (2) releases for VMS 5;

Three (3) releases for VMS 6; and

One (1) release for VMS 7.

The Contractor’s Trainer will conduct each release training over the course of two (2) week, totaling

twelve (12) weeks of training over the life of the project. Within each release training, there will be one

(1) session in Lansing, then three (3) sessions in Gaylord, and two (2) sessions in the Upper Peninsula.

Training may be conducted by the Testing and Training Manager and/or the Senior Business Analyst, as

well as one State‐provided, support trainer that has business subject matter expertise. The Contractor’s

Testing and Training Manager will work with the State to provision training facilities in each location.

Each training session will conclude with a trainee survey to validate participant understanding and

satisfaction with the training courses.

One (1) technical training session will be conducted during transition out, when maintenance and

support are transferred to the State. Technical training materials will be developed by the assigned

Contractor’s Maintenance Manager and training will be conducted by a member of the Contractor’s

Maintenance Team. Training will be conducted on‐site at DTMB’s location. DTMB will provide:

Provide Contractor’s Trainer access to the training location;

Computers for the trainees with the appropriate permission to access the VMS environments; and

A conference room with overhead projection.

Deliverable(s)

Training (electronic version only of materials and delivery)

SEM‐0301 Maintenance Plan

SEM‐0601 Conversion Plan

Revised SEM‐0603 Test Type Approach and Report

SEM‐0701 Transition Plan

SEM‐0702 Installation Plan

SEM‐0703 Training Plan

IS Service Request Hosting Solution (DTMB‐0184)

Operations Plan

Acceptance Criteria




Training Completed training tools that address the scope of functionality and additional maintenance and support introduced in the Release

Completed training tools that address hardware and technician responsibilities

Successful delivery of training as proposed

SEM‐0301 Maintenance Plan Plan content addresses all aspects of the solution, to include hardware and software

Plan clearly identifies the scope of maintenance efforts

Plan clearly identifies the processes and tools of the maintenance effort (staff and resources)

Plan clearly quantifies staff and resources for maintenance efforts

Plan clearly provides the overall flow of work within the maintenance process

Plan clearly establishes requirements for the maintenance staff


Revised SEM‐0603 Test Type Approach and Report

Revised Approach and Report clearly identifies all testing activities (e.g., tester training, environment setup, data setup, documentation setup, execution and reporting)

Revised Approach and Report clearly identifies criteria for successful completion

Revised Approach and Report clearly documents all test scenarios executed as expected and approved or defects reported

Revised Approach and Report clearly communicates defects as reported, logged, mitigated or resolved

Revised Approach and Report clearly reports and covers all test types (e.g., Unit, Integration, Functional, System/Standards, Performance, User Acceptance and Hardware)

SEM‐0601 Conversion Plan Plan clearly defines automated and manual conversions

Plan clearly defines the order in which the conversions occur

Plan clearly considers data volume

Plan clearly considers User work schedules, timeframes for reports and end‐of‐week, month, year procedures

Plan clearly considers criticality of the data

SEM‐0701 Transition Plan Plan clearly quantifies post‐transition operational needs

Plan clearly describes the procedures that will be used to perform the transition

The Plan clearly defines the manner in which the transfer of knowledge will occur

The Plan clearly defines the Contractor and State resources to participate in the transition

The Plan clearly defines what will be transitioned to State technicians and what will be transitioned subject matter experts

The Plan includes the application, interfaces, integrations configuration and operational support


Operations Plan Plan clearly defines application maintenance and support to include related tools, request management, request prioritization and release planning.

Plan clearly defines the Organization Chart, which includes State and Contractor staff, lines of authority to the next senior level of management and indicates who within the firm will have prime responsibility and final authority for the work.

Plan clearly defines the Scope Management Plan, which includes status monitoring activities and procedures to manage changes to the baseline scope.

Plan clearly defines Escalation Procedures which includes issue escalation and resolution procedures

Plan clearly defines the Procurement Management Plan, which includes a description of the hardware to be procured, identifies the procurement activities and any associated risks.

Plan clearly defines the procedure, tools, and related reports for tracking product issues and defects.

Plan is understandable, reasonable and accounts for all related tasks and resources (staff, equipment, tools, etc.)

SEM‐0606 Test Cases Test Cases clearly defines the set of test cases for each test type. Test Cases clearly explain each test case at a level of detail appropriate for the group conducting the testing (i.e., developers, QA testers, end users and technicians).

Test Cases cover all requirements

Test Cases clearly define the group to conduct each test case (i.e., developers, QA testers, end users and technicians)


SEM‐0701 Transition Plan Plan clearly quantifies post‐transition operational needs

Plan clearly describes the procedures that will be used to perform the transition

Plan clearly defines the manner in which the transfer of knowledge will occur

Plan clearly defines the Contractor and State resources to participate in the transition

Plan clearly defines what will be transitioned to State technicians and what will be transitioned to subject matter experts

Plan includes the application, hardware, interfaces, integrations configuration and operational support

SEM‐0702 Installation Plan Plan clearly defines how installation packages will be installed, validated and promoted from development into the testing and production environments

Plan clearly defines how hardware will be installed and tested

Plan includes web and database packages

Plan includes source code from which the object code or executable was created

Plan includes object code or executables

Plan includes development notes

Plan includes database scripts

Plan includes hardware components

Plan includes supporting documentation

Plan clearly considers continuity of operations

Plan clearly considers the business and operational needs of the users, maintenance staff, and management.

SEM‐0703 Training Plan Plan clearly defines the number and type of product demonstrations

Planning addresses hardware

Plan addresses end users, system administrators and technicians

Plan clearly defines the end user, system administrator and technician proficiency measures

Plan clearly defines the format of End User, System Administration, and Technical manuals

Plan identifies the training approach, methods, schedules, tools, and curricula.


IS Service Request Hosting Solution (DTMB‐0184)

Request clearly defines the infrastructure services needs

1.104.V Warranty

The Contractor will provide warranty of the implemented solution starting with the first accepted

release implementation and continuing for a minimum of one (1) year after the accepted

implementation of the final release. All functionality impacted by a release will be covered by the

warranty, including identified problems with existing or previous release functionality.

1.104.VI Maintenance and Support

The Contractor will provide Tier 2 support to the State’s Tier 1 user support for the duration of the

applicable Maintenance and Support, acknowledging support and maintenance requests within 1 hour

of receipt. There will no charge to the State for contacting the Contractor’s Tier 2 support. Tier 2

support will be available, at a minimum, one (1) hour before and one (1) hour after the hours of

operation for the State’s Tier 1 support, to include normal business operations, scheduled maintenance,

and emergency support.

At the State’s Tier 1 support discretion, support requests will be prioritized by severity as it relates to the

impact to the business area’s ability to maintain normal operations during normal business hours.

Contractor’s support and maintenance services will be provided through a help desk process, which will

include:

Questions regarding system functionality or processes

Defects identified during production operations

Production problems resulting from user error, resulting in data errors

Contractor will assume VMS 4 maintenance and support services, at the end of the warranty period. If

there are outstanding backlog items at the time of VMS 4 maintenance and support transition to

Contractor, the Contractor’s Maintenance Team will analyze the backlog, differentiating defect reports

from enhancement requests. Defects will be remedied as part of VMS 4 maintenance and support.

Enhancement requests will be handled with separate Statements of Work.

The Service Level Agreement that will govern the VMS 4, 5, 6, and 7 project, including specific activities,

roles and responsibilities, related materials and objectives are pursuant of the existing Contract

071B4300022 (the “Contract”).

The Contractor will use the State provided TFS tool as identified in the approved Operations Plan for

tracking Maintenance and Support requests and resolution.

The Operations Plan will define the process for managing the mutually agreed to set of values available

in the tracking tool.

The Operations Plan will include report content, format, frequency and distribution related to the

Contractor provided Tier 2 support.

The Contractor will participate in periodic review of the support metrics to identify trends, need for root

cause analysis, and process improvement opportunities.

The State has the option to extend Maintenance and Support via an annual renewal contract. The State

has the option to adjust applicable license counts and extended hardware warranty options with each

executed renewal. For any additional years Contractor will provide maintenance on a time and

materials basis pursuant to the rates in the existing Contract 071B4300022 (the “Contract”).

If the Contractor’s solution includes packaged software or software as a service, Maintenance and

Support includes all future software releases, updates and enhancements applicable to system modules

licensed without further charge to all licensed users maintaining the Maintenance and Support contract.

The Contract will provide an impact analysis to the State solution as part of the notification of the

license availability. The State has the right to decline the license.

The State will be provided with information on software/hardware/system problems encountered at

other locations not supported by this Contract, along with the solution to those problems, when such

information is relevant to State software.

Support is provided for superseded releases still in use by the State. For the Maintenance and Support

duration and all subsequent Maintenance and Support annual renewals, the following services are

provided for the current version and one previous version of any Software provided with the

deliverables, commencing upon installation of the deliverables or delivery of the Software:

Error Correction. Upon notice by State of a problem with the Software (for which problem can be

verified), reasonable efforts to correct or provide a working solution for the problem.

Material Defects. The State will be notified of any material errors or defects in the deliverables known,

or made known to Contractor from any source during the Contract term that could cause the production

of inaccurate, or otherwise materially incorrect, results and shall initiate actions as may be commercially

necessary or proper to effect corrections of any such errors or defects.

Updates. All new releases and bug fixes (collectively referred to as “Changes”) for any software

deliverable developed or published by Contractor and made generally available to its other customers at

no additional charge will be provided to the State at no additional charge.

Contractor’s support process is built around the following assumptions:

Defects are triaged based on their impact on the DNR operations:

o Tier 1 Defects – Have an immediate impact on production operations that negatively impact the validity of data or the ability to complete critical operations, which requires an emergency fix within 24 hours.

o Tier 2 Defects – Have a time‐sensitive impact on production operations, which requires an emergency fix before the normal release schedule.

o Tier 3 Defects – Need to be corrected, but can be grouped as part of the normal release schedule for the production application.

All production applications will have a published release schedule for correcting system defects. Schedule frequency varies depending on State‐indicated business criticality of the system and interaction with development activities.

Roles and Responsibilities:

Issues reported to the help desk will be entered into the JIRA defect tracking system. The following

table indicates the responsibilities of each organizational unit that will use JIRA.

Organization Unit Responsibilities Tasks

State of Michigan Staff Initiate defect

Close defect

Logs defect

Assist in priority determination

Test and acceptance of defect solution

Contractor’s Help Desk Coordinator

Initial contact with SOM Program Manager for defect management

Overall defect management

Works with SOM Program Manager to log and triage defect

Assigns defect to Contractor’s support staff for resolution for Tier 1 defects

Logs defect for Project Manager Review and release planning

Monitors service levels for overall maintenance activity

Contractor’s Support Staff

Defect analysis, correction and resolution

Analyze root cause of defect

Apply change

Perform testing

Move to production

Contractor’s Project Manager

Overall defect planning and management for supported application

Assign defect to release schedule

Monitor and manage progress

Inform client of progress

1.104.VII Future Enhancements Upon request and at the State’s sole option, the Contractor will provide additional goods or services to

meet changing needs and requirements. Contractor will ensure that sufficient technical resources are

available to address this requirement. To obtain Future Enhancements, the State will submit a SOW to

the Contractor for the additional goods and services requested. For each such SOW received from the

State, the Contractor will provide a Written Proposal, including a project plan and a quote based on the

rates established in Attachment A – Pricing. Upon review and written approval of the Written Proposal

by the DTMB PM and the Agency PM, the Agency will submit a contract change request to DTMB‐

Procurement in accordance with Section 1.403 Change Management of the parent contract

071B4300022. Upon review and written approval by DTMB‐Procurement, a contract amendment

(Change Notice) will be executed. A fully executed Change Notice is required prior to issuance of any

Purchase Order (PO). An issued PO is required prior to Contractor providing any goods or services under

this Section.

Unless otherwise requested, contractor will develop customizations at its own facilities. Contractor will

provide any customizations specifically requested by the State of Michigan, even if its other customers

have not requested similar customizations. Contractor will provide such services in a manner that meets

State requirements. Contractor will support testing to ensure the as‐built enhancements perform as

specified by the State. Contractor will provide test cases to the State that the contractor used in testing

the enhancements in advance of user acceptance testing. Contractor must not begin customization

work until they receive signoff.

Deliverable(s) Written Proposal including project plan and quote

Services upon the State’s request

Test cases

Acceptance Criteria: High‐level acceptance criteria per Section 1.500 Acceptance. Services conforming to each respective Statement of Work and Written Proposal.

1.105 FUNCTIONAL REQUIREMENTS

The Functional Requirements and definition for the for the Contractor provided VMS solution are

represented in the VMS 5, VMS 6, and VMS 7 Functional Specifications documents in Attachments A, B

and C. The Contractor will provide a solution that meets all of the indicated functional requirements.

1.200 Roles and Responsibilities

Roles and responsibilities applicable to this Statement of Work are in the existing contract between the

Contractor and the State of Michigan for MiCaRS development and support.

1.201 CONTRACTOR STAFF, ROLES, AND RESPONSIBILITIES 1.201.I Contractor Staff Contractor will provide sufficient qualified staffing to satisfy the deliverables of this Statement of Work.

Since an Agile process will be used, Contractor will provide the “Development Team”. The

Development Team is responsible for delivering the product at the end of each Sprint (the Sprint Goal).

A Development Team is made up of individuals with cross‐functional skills (i.e. Business Analyst, Senior

Software Engineer , System Architect, etc.) who do the actual work (analyze, design, develop, test,

technical communication, document, etc.). Contractor developers shall be responsible for writing,

configuring, testing, and installing software to satisfy requirements resulting in a high quality product

which functions as designed without errors.

1.201.I.A Key Personnel Contractor commits the following Key Personnel for the duration of the project:

1. Single Point of Contact (SPOC) and Contract Administrator

John K. Leigh, Partner

[email protected]

517‐202‐4625

The duties of the SPOC shall include, but not be limited to:

supporting the management of the Contract,

facilitating dispute resolution, and

advising the State of performance under the terms and conditions of the Contract.

2. Project Manager

Jeremy Harder

[email protected]

517‐643‐5283

The Contractor Project Manager shall interact with designated personnel from the State to insure a

smooth transition to the new system. The project manager will coordinate all of the activities of the

Contractor personnel assigned to the project and create all reports required by State. The Contractor's

Project Manager’s responsibilities include at a minimum:

Manage all defined Contractor responsibilities in the Scope of Services

Manage identified subcontractors

Develop the project management plan and schedule, updating as needed

Serve as the point person for all project issues

Coordinate and oversee the day‐to‐day project activities of the project team

Assess and report project feedback and status

Escalate project issues, project risks, and other concerns

Review all project deliverables and provide feedback

Proactively propose/suggest options and alternatives for consideration

Utilize change control procedures

Prepare project documents and materials

If an Agile process is proposed, then the Contractor – Project Manager will fulfill the agile Contractor

“Program Manager / Scrum Master” role. The agile Contractor Program Manager / Scrum Master

responsibilities include:

Manages planning process

Manages overall program schedule

Drives multiple releases for the contract

Facilitates Release Planning & Retrospective

Owns all action items for the project until he/she finds the right owner

Owns reporting on project status, to DTMB PM and DNR PC

Coordinates other release support

Responsible for risk assessment & mitigation

Finds and works to remove roadblocks

Facilitates communication between roles for every aspect of the project

Responsible for keeping release/project information consolidated, organized and up to date

Drives the cross‐functional team at all levels

Drives the execution of sprint items

Responsible for throughput (team velocity)

3. Business Analyst

Diane Wolcott

[email protected]

517‐347‐7618

The Contractor Business Analyst is responsible for eliciting functional and technical requirements, gap

analysis, meeting facilitation, documenting use case scenarios, perform business and workflow analysis.

4. Senior Software Engineer

Alex Morris

[email protected]

704‐560‐6713

The Senior Software Engineer is the development lead and has expert knowledge in matters of design

and build of the solution. The State anticipates the Senior Software Engineer will lead cross functional

teams of subject matter experts, developers, and business analyst and will facilitate workgroup

meetings.

5. System Architect

Garrett Radford

[email protected]

734‐751‐0712

The Contractor System Architect is responsible for leading and/or consulting on the development of the

System Architecture and work closely with the DTMB Architect to ensure the Solution satisfies

requirements and will function as designed in the State Enterprise network.

6. Training Manager

Diane Wolcott

[email protected]

517‐347‐7618

The Contractor Training Manager is responsible for effectively leading training resources, development

of the training plan, training manuals, and the execution of classes and other training opportunities.

7. Test Manager

Diane Wolcott

[email protected]

517‐347‐7618

The Contractor Test Manager is responsible for drafting, managing, and executing test scripts which

satisfy documented scenarios as mapped against the requirements traceability matrix. The test

manager is also responsible for drafting the test plan.

1.201.I.B Non-Key Personnel

Reserved

1.201.I.C Subcontractors

Reserved

1.201.I.D On Site Work Requirements

Location of Work:

The project manager and business analyst shall work 50% of the time at Constitution Hall, 525 West

Allegan, Lansing, Michigan 48909‐7952. Work performed in the execution of this contract must occur at

State facilities or Contractor offices located within 90 miles of Lansing Michigan, by individuals who are

legally qualified to perform the work as defined by State and Federal labor laws.

Tasks assigned to State resources will be executed in Lansing Michigan or as mutually agreed.

The State requires that the majority of contractor resources be physically co‐located with the team

within 90 miles of Lansing, Michigan when performing under this contract. The physical site may be

subject to State visits and audits. See 1.302 Project Status Reporting for required physical presence of

key project personnel.

The Contractor must identify in their proposal, with supporting justifications, the need to locate

resources in State owned facilities. The State will consider these requests but cannot guarantee

acceptance. In all scenarios it is the responsibility of the Contractor to secure space for Contractor

resources in support of the project.

Hours of Operation:

a. Normal State working hours are 8:00 a.m. to 5:00 p.m. EST, Monday through Friday, with work

performed as necessary after those hours to meet project deadlines. No overtime will be

authorized or paid.

b. The State is not obligated to provide State management of assigned work outside ofnormal

State working hours. The State reserves the right to modify the work hours in the best interest

of the project.

c. Contractor shall observe the same standard holidays as State employees. The State does not

compensate for holiday pay.

3. Travel:

a. No travel or expenses will be reimbursed. This includes travel costs related to training provided

to the State by Contractor.

b. Travel time will not be reimbursed.

Additional Security and Background Check Requirements:

Contractor must present certifications evidencing satisfactory Michigan State Police Background checks

ICHAT and drug tests for all staff identified for assignment to this project.

In addition, proposed Contractor personnel will be required to complete and submit an RI‐8 Fingerprint

Card for the National Crime Information Center (NCIC) Finger Prints, if required by project.

Contractor will pay for all costs associated with ensuring their staff meets all requirements.

1.201.II State Staff, Roles, and Responsibilities

If requested by the Contractor and approved by the DTMB PM, the State will provide the following

resources for the Contractor’s use on this project:

State ID for admittance into a State facility

Work space

Minimum clerical support

Telephone

PC workstation

Access to State servers and enterprise resources (e.g. email)

Access to printers

Access to copiers and fax machine

Access to conference rooms

The State reserves the right to suspend or revoke access to State resources at any time.

The State appoints the following staff:

1. Contract Administrator

Malathi Natarajan, IT Category Specialist

[email protected]

517‐284‐7030

2. Single Point of Contact (SPOC)

Mike Cooley

Cooleym@ michigan.gov

517‐373‐6608

The duties of the SPOC shall include, but not be limited to:

supporting the management of the Contract,

facilitating dispute resolution, and

advising the State of performance under the terms and conditions of the Contract.

2. State Project Manager – (DTMB PM)

Robin Krzciok [email protected] 517‐335‐3211

DTMB will provide a Project Manager who will act as the State’s SPOC for the Contractor, in regard

to this contract. The DTMB PM will provide the following services:

o Obtain the relevant DTMB, DNR, and/or State department/division concurrence(s) for any

Contractor requested change or standard deviation to this contract.

o Provide State facilities, as needed

o Coordinate the State resources necessary for the project

o Facilitate coordination between various external contractors

o Facilitate communication between different State departments/divisions

o Provide acceptance and sign‐off of deliverable/milestone

o Review and sign‐off of timesheets and invoices

o Resolve project issues – Shared responsibility with the Contrators PM/Scrum Master

o Escalate outstanding/high priority issues

o Utilize change control procedures

o Conduct regular and ongoing review of the project to confirm that it meets original

objectives and requirements

o Document and archive all important project decisions

o Arrange, schedule and facilitate State staff attendance at all project meetings.

The Contractor will fulfill the agile “Scrum Master” role. The agile Scrum Master responsibilities

include:

o Manages planning process

o Manages overall program schedule

o Drives multiple releases/projects

o Facilitates Release Planning & Retrospective

o Provides access to tools and people

o Owns all action items for the project until he/she finds the right owner

o Owns reporting on project status, to all directions

o Coordinates other release support

o Responsible for risk assessment & mitigation

o Facilitates Sprint Planning, Review & Retrospective

o Finds and works to remove roadblocks

o Facilitates communication between roles for every aspect of the project

o Responsible for keeping release/project information consolidated, organized and up to date

o Drives the cross‐functional team at all levels

o Drives the execution of sprint items

o Responsible for throughput (team velocity)

1. State Business Analyst (DTMB BA)

Mark Anderson

[email protected]

517‐335‐3328

DTMB – Business Analyst

The DTMB Business Analyst is responsible for executing and completing tasks assigned by the DTMB

PM, is expected to be knowledgeable in the application, and ensures DNR needs are being met.

2. DNR Co‐Sponsors

Bill O’Neill Lou Ann Fedewa

[email protected] [email protected]

517‐284‐5810 517‐284‐5860

DNR Sponsor

The DNR Sponsor represents the business executive leadership for the project. The DNR Sponsor

will coordinate with the DTMB Sponsor to:

o Resolve escalated project issues in a timely manner

o Review project management plan, schedule, status, and issues

o Resolve escalated deviations from project management plan or schedule

o Provide change control review and approval

o Ensure timely availability of escalated State resource issues

3. DTMB Sponsor

Manny Rosales

[email protected]

517‐284‐6006

DTMB Sponsor

The DTMB Sponsor represents the technology executive leadership for the project. The DTMB

Sponsor will coordinate with the DNR Sponsor to:

o Resolve escalated project issues in a timely manner


o Resolve escalated deviations from project management plan or schedule

o Provide change control review and approval

o Ensure timely availability of escalated State resource issues

4. Project Coordinator

Doug Heym

[email protected]

517‐284‐5867

DNR ‐ Project Coordinator (DNR PC)

The DNR Project Coordinator has expert knowledge in matters of requirements and is responsible

for assisting the DTMB PM in managing DNR resources in the execution of tasks.

o Resolve agency project issues in a timely manner


o Assist DTMB PM resolve deviations from the project management plan or schedule

o Provide acceptance sign off

o Utilize change control procedures

o Ensure timely availability of agency resources o Responsible for organizing and coordinating the testing for the DNR testers

The DNR PC will fulfill the “Product Owner ” role. The agile Product Owner’s responsibilities include:

o Communicating the vision of the product to the development team.

o Must also represent the Agency’s interests through requirements and prioritization. The

Product Owner shall have the sole authority to determine the prioritization of the original

requirements and all identified defects into the sprint and release backlog, regardless of

how such defects were identified (e.g., during a sprint demo, during UAT or otherwise, etc).

o Facilitates release planning and retrospectives

1.201.III Other Roles and Responsibilities

The State anticipates the following roles will be needed by the project and will assign resources to these

roles.

DTMB Roles

Project Owner

Business Analysts

Solution Architect

Subject Matter Experts (SMEs) by discipline

o Developer

o Web hosting

o Database

o Telecom

o Security o Quality Analyst o eMichigan Reviewer

DNR Roles

Project Coordinator

Subject Matter Experts (SMEs)

o Timber Sales

o TSale

o VMS

o MiFi

o OLB

o Other as identified

DTMB ‐ Project Owner

The DTMB Project Owner is responsible for assisting the DTMB PM in the execution of the project. This

includes but is not limited to the assignment of State resources.

DTMB – Business Analyst

The DTMB Business Analyst is responsible for executing and completing tasks assigned by the DTMB PM,

is expected to be knowledgeable in the application, and ensures DNR needs are being met.

DTMB – Solution Architect

The DTMB Solution Architect will coordinate with the DTMB PM to advise the Contractor in matters of

system design to ensure the LOTS Solution supports State standards and the State Enterprise

Environment.

DTMB – Subject Matter Expert(s)

A DTMB Subject Matter Expert is an individual who has expert knowledge of a technical subject or

requirement and is able to answer questions brought forward.

DNR ‐ Project Coordinator (DNR PC)

The DNR Project Coordinator has expert knowledge in matters of requirements and is responsible for

assisting the DTMB PM in managing DNR resources in the execution of tasks.

Resolve agency project issues in a timely manner

Review project management plan, schedule, status, and issues

Assist DTMB PM resolve deviations from the project management plan or schedule

Provide acceptance sign‐off

Utilize change control procedures

Ensure timely availability of agency resources

If an Agile process is proposed, then the DNR PC will fulfill the “Product Owner” role. The agile Product

Owner’s responsibilities include:

Communicating the vision of the product to the development team.

Must also represent the Agency’s interests through requirements and prioritization.

The Product Owner is the single individual who has project knowledge and the authority to

make decisions.

Facilitates release planning and retrospectives

DNR – Subject Matter Expert(s)

A DNR Subject Matter Expert is an individual who has expert knowledge of a business subject or

requirement and is able to answer questions brought forward.

Typical Assignments

Steering Committee

o DNR Sponsor

o DNR Project Coordinator

o DTMB Sponsor

o DTMB PM

o DTMB Project Owner

o Contractor Contract Manager

o Contractor PM

Project Leadership

o Contractor PM

o Contractor Senior Software Engineer

o DTMB PM



Project Change Control Board

o Contractor PM

o Contractor Senior Software Engineer

o DTMB PM



All data, materials, documentation and other things developed by the vendor for this project shall

belong exclusively to the State. This includes, but is not limited to, source code and

documentation. The State shall also own and retain intellectual property rights covering technology

developed as part of the services described herein.

1.300 Project Plan 1.301 PROJECT PLAN MANAGEMENT

Project Control

1. The Contractor will carry out this project under the direction and control of DNR and DTMB.

2. Within 5 working days of the execution of the Contract, the Contractor will submit the project plan

to the State Product Owner for final approval of the project plan. This project plan must be in

agreement with Section 1.104 Work and Deliverables, and must include the following:

a. The Contractor’s project organizational structure.

b. The Contractor’s staffing table with names and title of personnel assigned to the project. This

must be in agreement with staffing of accepted proposal. Necessary substitutions due to

change of employment status and other unforeseen circumstances may only be made with prior

approval of the State.

c. The project work breakdown structure (WBS) showing sub‐projects, activities and tasks, and

resources required and allocated to each.

d. The time‐phased plan in the form of a graphic display, showing each event, task, and decision

point in the WBS.

3. The Contractor will manage the project in accordance with the State Unified Information Technology

Environment (SUITE) methodology, which includes standards for project management, systems

engineering, and associated forms and templates which is available at

http://www.michigan.gov/suite

a. Contractor will use a project management tool for planning, monitoring, and tracking the

Contract’s progress and the level of effort of any Contractor personnel spent performing

Services under the Contract. The tool shall have the capability to produce:

i. Staffing tables with names of personnel assigned to Contract tasks.

ii. Project plans showing tasks, subtasks, deliverables, and the resources required and

allocated to each (including detailed plans for all Services to be performed under this

contract, updated bi‐weekly).

iii. Updates must include actual time spent on each task and a revised estimate to complete.

iv. Graphs showing critical events, dependencies and decision points during the course of the

Contract.

1.302 Project Status Reporting

Reporting formats must be submitted to the State’s Product Owner for approval within ten (10) business

days after the execution of the contract resulting from this request. Once both parties have agreed to

the format of the report, it shall become the standard to follow for the duration of the contract.

The project reporting period will be weekly, with each report due on Monday. Each status report will

be based on SUITE/PMM and include:

Project status

Updated project plan

Summary of activity during the report period

Accomplishments during the report period

Deliverable status

Finances (milestone billing points – expected, completed, amount)

Schedule status

Action Item status

Issues

Change Control

Repair status

Maintenance Activity

Risks

Next Steps

1.400 Project Management

1.401 Issue Management

Reserved

1.402 Risk Management

Reserved

1.403 Change Management

Reserved

1.500 Acceptance 1.501 Criteria

The following criteria will be used by the State to determine Acceptance of the services and deliverables:

Document Deliverables

Documents are dated and in electronic format, as mutually agreed with the State.

Requirements documents are reviewed and updated throughout the development process to

assure requirements are delivered in the final product.

Draft documents are not accepted as final deliverables.

The documents will be reviewed and accepted in accordance with the requirements of the

Contract.

DTMB will review documents within a mutually agreed upon timeframe.

Approvals will be written and signed by DTMB PM, DTMB Project Owner and by DNR Product

Owner.

Issues will be documented and submitted to the Contractor.

After issues are resolved or waived, the Contractor will resubmit documents for approval within 30 days

of receipt.

Software Deliverables

Software will be grouped into “Releases”, based on the Deliverable / milestones eligible for payment.

Software acceptance, for each Release, can be achieved through a series of steps, conditions, and

approvals:

Beta software is not accepted as part of any release.

The software will be reviewed and accepted in accordance with the requirements of the

contract.

DTMB and DNR will review software within a mutually agreed upon timeframe for acceptance of

functionality, usability, installation, performance, security, standards compliance,

backup/recovery, and operation.

o Approvals will be written and signed by DTMB PM, DTMB Project Owner and the DNR VMS

Product Owner.

o Unacceptable issues will be documented and submitted to the Contractor.

o After issues are resolved or waived, the Contractor will resubmit software for approval within 30

days of receipt.

Software is installed and configured, with assistance from DTMB, in an appropriate environment

(e.g. DEV, QA, PROD).

Contingency plans, de‐installation procedures, and software are provided by the Contractor and

approved by DTMB PM and the DNR Product Owner.

Acceptance of the software will depend on the successful completion of User Acceptance

Testing (UAT).

Testing will demonstrate the system’s compliance with the requirements of the contract. At a

minimum, the testing will confirm the following:

o Functional ‐ the capabilities of the system with respect to the functions and features described

in the contract.

o Performance ‐ the ability of the system to perform the workload throughput requirements. All

problems should be completed satisfactorily within the allotted time frame.

o All deviations from the contract requirements, as determined by the State, shall be logged and

tracked as defects. Each defect will be categorized by the State as an S1 (Business Critical

Failures), S2 (System Defect with Work‐around), or S3 (Minor Error).

o A defect may be determined by the State to be resolved, if the deviation from the contract

requirement is no longer present.

o A defect may be determined by the State to be mitigated, if the deviation from the contract

requirement has an available work‐around which imposes a trivial business impact.

o An unresolved or unmitigated defect may be subject to liquidated damages.

DTMB will review test software, data, and results within a mutually agreed upon timeframe.

o Approvals will be written and signed by DTMB PM, DTMB Project Owner and the DNR Product

Owner.


o After issues are resolved or waived, the Contractor will resubmit test software, data and results

for approval within 30 days of receipt.

Software source code, where applicable, is reviewed by DTMB within a mutually agreed upon

timeframe for readability, structure, and configuration management.

o Approvals will be written and signed by DTMB PM, DTMB Project Owner and the DNR Product

Owner.


o After issues are resolved or waived, the Contractor will resubmit source code for approval within

30 days of receipt.

Acceptance of the software will depend on the successful completion of the Warranty Period.

All open S1 or S2 defects, as determined by the State, must be resolved before the Warranty

Period may be successfully completed. An unresolved defect may be subject to liquidated

damages.

1.502 Final Acceptance

Final acceptance will occur when all deliverables defined in Attachment A – Pricing and per the

acceptance criteria defined in Section 1.500 Acceptance have been completed and written approval

have been obtained (“Final Acceptance”). Final acceptance will be given after the expiration of the

Warranty Period if all outstanding issues have been resolved to the State’s satisfaction. See also the

Contract Terms for further details.

In the event the work and/or deliverable is not accepted by the DTMB PM and the DNR Product Owner,

the State will respond to the Contractor with written notice describing the deficiencies using a corrective

action plan listing tasks with associated completion dates. The contractor has five (5) business days to

respond to the notice indicating agreement to the terms unless an alternate solution is agreed by both

parties. Upon completion, State will have ten (10) business days to accept and approve the revised

deliverable(s).

If the State does not approve the revised deliverable(s) after the third (3rd) attempt, the State shall have

the option to negotiate an acceptable alternative, collect penalties for the incomplete and/or late

deliverable, or terminate the Contract pursuant to Termination for Cause.

1.600 Compensation and Payment

Method of Payment

The project will be paid on a firm fixed price basis, including all post‐implementation, less identified

holdbacks (see Section 1.601). Maintenance and support will be paid on Time and material basis in

accordance with the rates provided in the base contract 071B4300022. All costs associated with future

enhancements will be submitted in a contract change notice with a Statement of Work for a firm fixed

price in accordance with the Contractor’s rate card. Payment will only be made upon successful

completion and State’s formal acceptance of milestone items listed in the Attachment A – Pricing and

upon the agreed schedule as in Attachment B – Payment Schedule.

Travel

The State will NOT pay for any travel expenses, including hotel, mileage, meals, parking, etc. except for

meals and lodging, at the State rate, while facilitating training outside of Lansing. Travel time will not be

reimbursed.

Invoicing

Contractor will submit properly itemized invoices for approved deliverables to:

DTMB – Financial Services

Accounts Payable

P.O. Box 30026

Lansing, MI 48909

or

DTMB‐Accounts‐[email protected]

Incorrect or incomplete invoices will be returned to Contractor for correction and reissue.

1.601 Holdback

The State will hold-back an amount equal to ten percent (10%) of all amounts invoiced by the Contractor for Services/Deliverables. The hold-back amounts shall be released to the Contractor after the State has granted Acceptance for each of the following modules, VMS 5.0, 6.0 and 7.0

Attachment A - Pricing

Table of Contents age intentionally blank to support duplex printing.

Summary

Contractor to complete the summary table below. Costs for each row should match the total of each of the detailed tables in the following sections.

Section Project Costs Cost

2.100 Planning (Sprint Zero / Initial Docs) $226,440

2.201 Release 1 / Warranty 1 $1,258,200

2.202 Release 2 / Warranty 2 $397,800







1.300 Project Closeout $36,000

Project Total $4,691,400

1.400 VMS 4 Maintenance and Support T & M Rates

1.500 Each Additional Year Maintenance T & M Rates

Project Cost Plus Optional Future Enhancements

Cost Item Cost

Project Costs $4,691,400

Optional Future Enhancements $470,000

Total Contract Value $5,161,400

Planning (Sprint Zero/Initial Docs)

Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in the planning sprint for the complete scope of work. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.

Milestone Activities Cost

10% Hold-back

Transition-In Kickoff $6,520 $652 PMM-0101 Project Charter $3,000 $300 PMM-0102 Project Managment Plan $7,000 $700 Enterprise Architecture Solution Assessment $8,600 $860 Project Schedule $7,000 $700

DTMB-0170 Security Plan and Assessment (LockPath) $8,600 $860

Bootstrapping $110,120 $11,012 Requirements Validation and Release Planning Requirements Validation and Release Planning $22,000 $2,200 Definition of Scope $22,000 $2,200 Initial Product Backlog $19,600 $1,960 SEM-0301 Maintenance Plan (initial) $6,000 $600

SEM-0302 Software Configuration Management Plan (initial) $6,000 $600

Total Cost $226,440 $22,644

Releases

2.301 RELEASE 1 / WARRANTY 1

Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in the release for the complete scope of work. At a minimum, milestones are expected for each sprint. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.

Milestones Activities Cost

10% Hold-back

Release 1 Sprints Product Backlog Grooming $125,040 $12,504

Sprint Planning $61,920 $6,192

Application Development $626,400 $62,640

Internal QA $256,800 $25,680

Sprint Review $30,960 $3,096

Sprint Retrospective $30,960 $3,096

Development Deliverables SEM-0302 Software Configuration Management Plan $2,720 $272

SEM-0501 Functional Design $3,000 $300

SEM-0601 Conversion Plan $3,360 $336

SEM-0602 Test Plan $3,400 $340

SEM-0603 Test Type Approach and Report $3,400 $340

SEM-0604 System Design Document $10,600 $1,060

eMichigan Review $7,680 $768

Enterprise Architecture (EA) Assessment $3,440 $344

Project Security Plan and Assessment (DTMB-0170/LockPath) $8,600 $860

Operations Plan $1,720 $172

Requirements Traceability Matrix $1,800 $180

Testing Installation and Configuration of QA Environment $15,760 $1,576

User Acceptance Testing Execution $17,160 $1,716

Training SEM-0703 Training Plan $4,200 $420

Training Guides $10,600 $1,060

Training Execution $20,000 $2,000

Implementation SEM-0701 Transition Plan $1,760 $176

SEM-0702 Installation Plan $2,760 $276

Installation and Configuration of Production Environment $4,160 $416

Total Cost $1,258,200 $125,820


Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in the release for the complete scope of work. At a minimum, milestones are expected for each sprint. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the

Statement of Work.


10% Hold-back




Internal QA $80,800 $8,080

Sprint Review $9,360 $936

Sprint Retrospective $9,360 $936

Development Deliverables SEM-0302 Software Configuration Management Plan $970 $97


SEM-0601 Conversion Plan $860 $86

SEM-0602 Test Plan $450 $45

SEM-0603 Test Type Approach and Report $900 $90

SEM-0604 System Design Document $2,940 $294


Enterprise Architecture (EA) Assessment $360 $36


Operations Plan $860 $86




Training SEM-0703 Training Plan $900 $90

Training Guides $1,700 $170





Total Cost $397,800 $39,780




10% Hold-back




Internal QA $57,000 $5,700













Requirements Traceability Matrix $450 $45





Training Execution $0 $0

Implementation SEM-0701 Transition Plan $430 $43

SEM-0702 Installation Plan $860 $86


Total Cost $257,400 $25,740




10% Hold-back




Internal QA $78,400 $7,840


















Training Execution $0 $0




Total Cost $351,000 $35,100




10% Hold-back

Release Sprints Product Backlog Grooming $76,000 $7,600



Internal QA $229,600 $22,960







SEM-0603 Test Type Approach and Report $1,600 $160















Total Cost $868,200 $86,820




10% Hold-back




Internal QA $46,000 $4,600















User Acceptance Testing Execution $9,860 $986







Total Cost $257,400 $25,740




10% Hold-back




Internal QA $46,000 $4,600






















Total Cost $257,400 $25,740


Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in the release for the complete scope of work. At a minimum, milestones are expected for

each sprint. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.


10% Hold-back




Internal QA $148,200 $14,820



Development Deliverables SEM-0302 Software Configuration Management Plan $1,720 $172

SEM-0501 Functional Design $11,440 $1,144



SEM-0603 Test Type Approach and Report $10,000 $1,000

SEM-0604 System Design Document $13,600 $1,360

eMichigan Review $18,000 $1,800


Project Security Plan and Assessment (DTMB-0170/LockPath) $12,160 $1,216





Training SEM-0703 Training Plan $1,400 $140





Installation and Configuration of Production Environment $10,920 $1,092

Total Cost $781,560 $78,156

Project Closeout

Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in Project Closeout for the complete scope of work. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.

Milestone Activities Cost

Project Closeout Project Closure Report $36,000

Total Cost $36,000

Future Enhancements

Contractor to define and fill out the following table to represent the Resource Type and associated Hourly Rate supporting each Future Enhancement identified by the State. Prices quoted will be firm for the entire length of VMS 5, 6 and 7 Phases. Optional years may not be increased by more than 4% of the previous year.

Resource Type Not-to-Exceed Hourly RateProject management $125Business analysts $100System analysts $100Programmer/developers $90System Architects $115

VMS 4 Maintenance and Support

Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone for VMS 4 Maintenance and Support for the complete scope of work. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.

Milestone Activities CostVMS 4 Maintenance and Support

Environment Training / Knowledge Transfer

Defect Tracking / Management Defect Resolution / Testing / Releases

/ Documentation Time and Material

Rates*

* Time and material rates are provided in the MiCaRS Maintenance and Support contract.

Each Additional Year Maintenance

Contractor to define and fill out the following table to represent the activities and associated cost supporting each milestone in each additional year of maintenance for the complete scope of work. Tasks must address the deliverables in scope and adhere to SUITE and section 1.103 in the Statement of Work.

Milestone Activities CostYearly Maintenance Defect Tracking / Management

Defect Resolution / Testing / Releases / Documentation

Time and Material Rates*

* Time and material rates are provided in the MiCaRS Maintenance and Support contract.

Attachment B – Payment Schedule

Release Milestone Activity Activity Start

Activity End Amount Due

10% Holdback

Invoice Amount

Transition‐In Transition‐In Kickoff 5/15/2017 5/19/2017 $6,520.00 $652.00 $5,868.00

Transition‐In Transition‐In PMM‐0101 Project Charter 5/15/2017 5/26/2017 $3,000.00 $300.00 $2,700.00

Transition‐In Transition‐In PMM‐0102 Project Managment Plan 5/15/2017 5/26/2017 $7,000.00 $700.00 $6,300.00

Transition‐In Transition‐In Enterprise Architecture Solution Assessment 5/15/2017 5/25/2017 $8,600.00 $860.00 $7,740.00

Transition‐In Transition‐In Project Schedule 5/15/2017 5/25/2017 $7,000.00 $700.00 $6,300.00

Transition‐In Transition‐In

DTMB‐0170/LockPath Security Plan and Assessment 5/30/2017 6/29/2017 $8,600.00 $860.00 $7,740.00

Transition‐In Transition‐In Bootstrapping 5/15/2017 6/29/2017 $110,120.00 $11,012.00 $99,108.00

Requirements Validation and Release Planning


Requirements Validation and Release Planning 6/30/2017 7/21/2017 $22,000.00 $2,200.00 $19,800.00



SEM‐0301 Maintenance Plan (initial) 6/30/2017 8/8/2017 $6,000.00 $600.00 $5,400.00



SEM‐0302 Software Configuration Management Plan (initial) 6/30/2017 8/8/2017 $6,000.00 $600.00 $5,400.00


Requirements Validation and Release Planning Definition of Scope 7/24/2017 8/25/2017 $22,000.00 $2,200.00 $19,800.00


Requirements Validation and Release Planning Initial Product Backlog 7/24/2017 8/29/2017 $19,600.00 $1,960.00 $17,640.00

Release 1 Release 1 Sprints Product Backlog Grooming 6/30/2017 7/14/2017 $4,465.71 $446.57 $4,019.14

Release 1 Release 1 Sprints Sprint Planning 6/30/2017 7/14/2017 $2,211.43 $221.14 $1,990.29

Release 1 Release 1 Sprints Application Development 6/30/2017 7/14/2017 $22,371.43 $2,237.14 $20,134.29

Release 1 Release 1 Sprints Internal QA 6/30/2017 7/14/2017 $9,171.43 $917.14 $8,254.29

Release 1 Release 1 Sprints Sprint Review 6/30/2017 7/14/2017 $1,105.71 $110.57 $995.14

Release 1 Release 1 Sprints Sprint Retrospective 6/30/2017 7/14/2017 $1,105.71 $110.57 $995.14






















Release 1 Development Deliverables

SEM‐0302 Software Configuration Management Plan 6/30/2017 10/19/2018 $2,720.00 $272.00 $2,448.00


SEM‐0501 Functional Design 6/30/2017 10/19/2018 $3,000.00 $300.00 $2,700.00


SEM‐0601 Conversion Plan 7/24/2017 10/19/2018 $3,360.00 $336.00 $3,024.00

Release 1 Development Deliverables SEM‐0602 Test Plan 7/24/2017 10/19/2018 $3,400.00 $340.00 $3,060.00


SEM‐0603 Test Type Approach and Report 8/14/2017 10/19/2018 $3,400.00 $340.00 $3,060.00


SEM‐0604 System Design Document 8/14/2017 10/19/2018 $10,600.00 $1,060.00 $9,540.00

Release 1 Development Deliverables eMichigan Review 6/30/2017 10/19/2018 $7,680.00 $768.00 $6,912.00


Enterprise Architecture (EA) Assessment 6/30/2017 10/19/2018 $3,440.00 $344.00 $3,096.00


Project Security Plan and Assessment (DTMB‐0170/ LockPath) 6/30/2017 10/19/2018 $8,600.00 $860.00 $7,740.00

Release 1 Development Deliverables Operations Plan 8/14/2017 10/19/2018 $1,720.00 $172.00 $1,548.00


Requirements Traceability Matrix 7/24/2017 10/19/2018 $1,800.00 $180.00 $1,620.00

Release 1 Testing

Installation and Configuration of QA Environment 8/15/2018 8/21/2018 $15,760.00 $1,576.00 $14,184.00

Release 1 Testing User Acceptance Testing Execution 8/22/2018 9/19/2018 $17,160.00 $1,716.00 $15,444.00

Release 1 Training SEM‐0703 Training Plan 8/30/2017 7/5/2018 $4,200.00 $420.00 $3,780.00

Release 1 Training Training Guides 6/30/2017 10/10/2018 $10,600.00 $1,060.00 $9,540.00

Release 1 Training Training Execution 9/27/2018 10/10/2018 $20,000.00 $2,000.00 $18,000.00

Release 1 Implementation SEM‐0701 Transition Plan 7/3/2018 8/9/2018 $1,760.00 $176.00 $1,584.00

Release 1 Implementation SEM‐0702 Installation Plan 8/18/2018 9/18/2018 $2,760.00 $276.00 $2,484.00

Release 1 Implementation

Installation and Configuration of Production Environment 9/27/2018 10/19/2018 $4,160.00 $416.00 $3,744.00




Release 2 Release 2 Sprints Internal QA 8/22/2018 9/5/2018 $10,100.00 $1,010.00 $9,090.00

Release 2 Release 2 Sprints Sprint Review 8/22/2018 9/5/2018 $1,170.00 $117.00 $1,053.00

Release 2 Release 2 Sprints Sprint Retrospective 8/22/2018 9/5/2018 $1,170.00 $117.00 $1,053.00












































SEM‐0302 Software Configuration Management Plan 8/22/2018 2/28/2019 $970.00 $97.00 $873.00




SEM‐0601 Conversion Plan 8/22/2018 2/28/2019 $860.00 $86.00 $774.00

Release 2 Development Deliverables SEM‐0602 Test Plan 8/22/2018 2/28/2019 $450.00 $45.00 $405.00


SEM‐0603 Test Type Approach and Report 8/22/2018 2/28/2019 $900.00 $90.00 $810.00


SEM‐0604 System Design Document 8/22/2018 2/28/2019 $2,940.00 $294.00 $2,646.00



Enterprise Architecture (EA) Assessment 8/22/2018 2/28/2019 $360.00 $36.00 $324.00


Project Security Plan and Assessment (DTMB‐0170/LockPath) 8/22/2018 2/28/2019 $1,720.00 $172.00 $1,548.00

Release 2 Development Deliverables Operations Plan 8/22/2018 2/28/2019 $860.00 $86.00 $774.00


Requirements Traceability Matrix 8/22/2018 2/28/2019 $1,050.00 $105.00 $945.00

Release 2 Testing



Release 2 Training SEM‐0703 Training Plan 8/22/2018 2/19/2019 $900.00 $90.00 $810.00

Release 2 Training Training Guides 8/22/2018 2/19/2019 $1,700.00 $170.00 $1,530.00


Release 2 Implementation SEM‐0701 Transition Plan 11/1/2018 12/12/2018 $1,010.00 $101.00 $909.00




















































Requirements Traceability Matrix 12/18/2018 5/9/2019 $450.00 $45.00 $405.00

Release 3 Testing



Release 3 Training SEM‐0703 Training Plan $0.00 $0.00 $0.00


Release 3 Training Training Execution $0.00 $0.00 $0.00

Release 3 Implementation SEM‐0701 Transition Plan 2/20/2019 3/6/2019 $430.00 $43.00 $387.00

Release 3 Implementation SEM‐0702 Installation Plan 3/7/2019 3/21/2019 $860.00 $86.00 $774.00

























Project Security Plan and Assessment (DTMB‐0170/LockPath) 3/20/2019 8/26/2019 $1,720.00 $172.00 $1,548.00




Release 4 Testing



Release 4 Training SEM‐0703 Training Plan $0.00 $0.00 $0.00


Release 4 Training Training Execution $0.00 $0.00 $0.00







































SEM‐0603 Test Type Approach and Report 7/5/2019 5/18/2020 $1,600.00 $160.00 $1,440.00











Release 5 Testing


























Release 6 Testing


Release 6 Testing User Acceptance Testing Execution 5/22/2020 6/12/2020 $9,860.00 $986.00 $8,874.00



















Release 7 Testing
















































SEM‐0302 Software Configuration Management Plan 8/11/2020 4/15/2021 $1,720.00 $172.00 $1,548.00


SEM‐0501 Functional Design 8/11/2020 4/15/2021 $11,440.00 $1,144.00 $10,296.00


SEM‐0601 Conversion Plan 8/11/2020 4/15/2021 $1,000.00 $100.00 $900.00



SEM‐0603 Test Type Approach and Report 8/11/2020 4/15/2021 $10,000.00 $1,000.00 $9,000.00


SEM‐0604 System Design Document 8/11/2020 4/15/2021 $13,600.00 $1,360.00 $12,240.00

Release 8 Development Deliverables eMichigan Review 8/11/2020 4/15/2021 $18,000.00 $1,800.00 $16,200.00




Project Security Plan and Assessment (DTMB‐0170/ LockPath) 8/11/2020 4/15/2021 $12,160.00 $1,216.00 $10,944.00




Release 8 Testing



Release 8 Training SEM‐0703 Training Plan 8/11/2021 2/11/2021 $1,400.00 $140.00 $1,260.00



Release 8 Implementation SEM‐0701 Transition Plan 1/26/2021 2/9/2021 $1,720.00 $172.00 $1,548.00



Installation and Configuration of Production Environment 3/24/2021 4/15/2021 $10,920.00 $1,092.00 $9,828.00

Project Closeout Project Closeout Project Closeout 4/16/2021 5/13/21 $36,000.00 $3,600.00 $32,400.00

Grand Total $4,691,400.00 $469,140.00 $4,222,260.00

Revised 4/7/2016


Change Notice Number 10 . to

Contract Number 071B4300022

CO

NT

RA

CT

OR


ST

AT

E

Pro

gram

M

anag

er Susan Nordyke DTMB

28081 Southfield Road 517-373-9784

Lathrup village, MI 48076 [email protected]

John Leigh

Co

ntra

ct

Adm

inis

trat

or

Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective September 26, 2016, this Contract is hereby increased by $13,450.00 to provide Request Management System (RMS) enhancements and upgrades that will increase Out-of-State Resident Services (OSRS) efficiency by adding additional functionality. See attached Statement of Work dated September 22, 2016. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor and agency agreement, and DTMB Procurement approval.


CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services MIRS rPS ARS

INITIAL EFFECTIVE DATE INITIAL EXPIRATION DATE

INITIAL AVAILABLE OPTIONS

EXPIRATION DATE BEFORE CHANGE(S) NOTED BELOW




☐ P-card ☐ Direct Voucher (DV) ☐ Other ☐ Yes ☒ No MINIMUM DELIVERY REQUIREMENTS


OPTION LENGTH OF OPTION EXTENSION LENGTH OF EXTENSION

REVISED EXP. DATE

☐ ☐


$5,766,288.37 $13,450.00 $5,779,738.37

Revised 4/7/2016



STATEMENT OF WORK

Project Title: SSS RMS Enhancements

Period of Coverage: 09/26/2016 – 09/30/2017

Requesting Department: MDOS

Date: 9/22/2016

Agency Project Manager: Lona Angel

Phone: 517-636-4422

DTMB Contract Administrator:

Phone:


BACKGROUND: SSS RMS is in need of enhancements to the current system used. There are three enhancements needed and they are described below in the scope of work. PROJECT OBJECTIVE:

The approach used for a project is an important part of a project’s success. Of course, a project will have a

better opportunity of success if it has the required funding, skilled resources, executive support, limited

impediments, and limited constraints. However, a project can have all of the right ingredients, but still fail, if

the project does not have a clear project approach.

MDOS has requested services for Kunz, Leigh and Associates to perform development for enhancements.

Over the 8‐week schedule, the enhancements will be developed, tested internally and then finally tested by

the user (User Acceptance Testing) before proceeding to production.

The State of Michigan has addressed the need for a clear project approach by providing projects with a

framework, the State Unified Information Technology Environment (SUITE), which provides documented

methodologies for project management and systems engineering.

“The overall purpose of SUITE is to bring the Department of Technology, Management &

Budget (DTMB) systems development areas up to CMMI Level 3, which ensures consistent

process usage throughout the organization. This includes using the same Project

Management Methodology (PMM), Systems Engineering Methodology (SEM), Process

Management, and Supporting Processes across all systems development areas within DTMB.

The overall goal of SUITE is to integrate Project Management, Systems Engineering, Process

Management, and Supporting Processes into a single unified environment.”

The SSS RMS enhancement project will adhere to SUITE, producing the required documentation with the PMM

Revised 4/7/2016

and SEM document templates.

The project will integrate the SUITE requirements into the system development life cycle (SDLC) by following

the SUITE PMM/SEM Integration for Agile, with the Scrum Framework as the Agile derivative.

The following illustration depicts a typical Scrum iteration, showing how each Sprint encompasses all SDLC

phases, beginning with requirement analysis through testing to product deployment.


DTMB will provide the necessary hardware for a development environment, a staging/testing environment,

and a production environment. KL&A will work with DTMB to get these environments implemented.

The high‐level requirements for this project have already been identified. These requirements will be entered

into the “product backlog” in Team Foundation Server. The State will have access to this “product backlog” as

needed. Functional and system design will occur at the beginning of the development cycle. Design

information will be documented in SEM‐0501 and SEM‐0604.

The function(s) developed will be deployed to the staging/testing environment, where they will be fully tested

with functional testing, system integration testing (SIT), and user acceptance testing (UAT) that occurs at the

end of the Sprint. The Business Analyst will write test cases for each requirement and bundle the test cases

into a test plan for the release. Each test plan will contain a phase for SIT and a phase for UAT. The Business

Analyst will execute and track SIT test outcomes and will ensure that the KL&A Developers repair any defects.

After the SIT phase is complete, the KL&A Project Manager will facilitate UAT with identified MDOS personnel,

who will also track test outcomes. Tracking test outcomes is as simple as executing the steps identified in the

test case and marking each step as passed or failed. The KL&A Project Manager will ensure that any defects

found during UAT are repaired to the satisfaction of MDOS.

Revised 4/7/2016

When all features defined in the project scope have passed user acceptance testing, KL&A will work with DTMB

to deploy the final release version to the production environment. MDOS will provide written acceptance and

remit payment.

SCOPE OF WORK: The proposed solution involves the following:

Restrict Requests Being Backdated

The system and users need validation in which they cannot backdate to a reconciliation that has already been completed.

Ability to backdate Suspended On

In some cases, a suspended request needs to have its date changed and backdated. Currently, the system does not allow this and will with this enhancement.

Show Warning if Suspending a Request When Completed

Currently, when suspending a request that is completed the user does not have any way of knowing that the request is complete and allows the user to suspend it. New functionality will be developed to alert the user when this happens.

If the above scope negatively affects SSS RMS, remediation changes will be made as part of KL&A maintenance support contract at no cost to MDOS. Negative can be defined as anything that doesn’t work as planned, any error that has a significant and unwanted impact on the function, reliability or output of the system.

The scope of work necessary to achieve this solution includes:

Working with DTMB to ensure the appropriate changes are implemented.

Creating SUITE PMM and SEM documentation, listed in “Deliverables”

Creating enhancements stated above

Working with DTMB and MDOS personnel

TASKS: Technical support is required to assist with the following tasks: • When all features defined in the project scope have passed user acceptance testing, KL&A will provide DTMB an implementation plan that includes all necessary scripts that DTMB can deploy to the final release version to the production environment.

Table 1. Project Assumptions

Project Assumptions

• This project will be developed with the Scrum (Agile) methodology, delivering

Revised 4/7/2016

functionality through a series of releases; each release will provide a project milestone.

• The project start date will begin upon of receipt of the purchase order.

• The project contains dependencies on DTMB for hardware that can impact the completion date of the project.

• KL&A observes the following non‐working holidays, Election day (November 8), Veterans day (November 11), Thanksgiving days (November 26 and 27)

• All other non‐weekend calendar days, and non‐State holidays, are treated as work days, with the assumption that both KL&A and MDOS stakeholders are available to complete project‐related tasks.

• This proposal is a fixed‐price bid. Change requests approved by MDOS or DTMB will affect the price and schedule as defined within the request of change (RFC).

• KL&A will provide test cases and test plans for user acceptance testing (UAT) prior to each release and will facilitate UAT.

• UAT will be concluded within 5 business days of each Sprint release.

• Any failures reported during UAT that KL&A and MDOS deem outside the scope of this project will be handled through a “change request” process, in which KL&A will submit the request for change (RFC) to DTMB.

• DTMB will be responsible for evaluating and approving or declining any RFC initiated by KL&A or the MDOS, and the project schedule, pricing, and payment schedule will be updated accordingly.

• DTMB will be responsible for executing the scripts identified within the implementation plan for deploying the releases to production. KL&A will initiate the release process via an RFC.

• DTMB will be responsible for deploying releases to the Test server.

• KL&A will deliver source code with each release deployment.


Role Responsibility

KL&A Project Manager • Facilitate meetings

• Maintain project schedule

• Communicate with MDOS and DTMB

• Complete PMM deliverables

• Ensure all SEM deliverables are completed

• Manage development team

KL&A Developer • Develop the application

• Unit testing

• Code reviews

PROJECT SCHEDULE AND ESTIMATED RESOURCES:

Revised 4/7/2016

Contractor’s preliminary, high-level Project Schedule for this Project is estimated as follows:

Task Contractor’s Resource Title

Approximate Hours

Anticipated Start Date

(Month/Year)

1. Business Requirements

2. Gathering/JAD Sessions

Dev/PM -- 10/10/2016

JAD Session Dev/PM 4 10/10/2016

Requirements Gathering

Dev/PM 5 10/11/2016

3. Documentation PM -- 10/10/2016

Update Functional Design Document

PM 3 10/12/2016

Update System Design Document

PM 3 10/12/2016

Create Test Cases PM 7 10/13/2016

4. System Development Dev/PM -- 10/14/2016

Restrict Requests Being Backdated

Dev/PM 40 10/14/2016

Ability to Backdate Suspended On

Dev/PM 24 10/21/2016

Show Warning if Suspending a Request When Completed

Dev/PM 16 10/26/2016

5. User Acceptance Testing

Dev/PM -- 11/9/2016

User Testing Dev/PM 5 11/9/2016

User Testing Fixes Dev/PM -- Unknown

User Testing Dev/PM 5 11/11/2016

UAT Business Owner Write-Off

Dev/PM 2 11/11/2016

6. Production PM -- 11/14/2016

Revised 4/7/2016

Implementation

Implementation Plan Review

PM 5 11/14/2016

7. Production Go-Live Dev/PM -- 11/11/2016

Complete RFC Document

PM 4 11/11/2016

Submit RFC Document

PM 1 11/14/2016

Implementation PM 3 12/5/2016

Verification Testing Dev/PM 2 12/5/2016

Go-Live Business Owner Write-Off

PM 1 12/5/2016

8. Project Completion All 130 12/5/2016

DELIVERABLES: Deliverables will not be considered complete until the Agency Project Manager has formally accepted them. Deliverables for this project include:

Updated SEM‐0501 Functional Design Document


Application Code

New and Enhanced System Functionality (Releases)

Project Schedule

ACCEPTANCE CRITERIA:

The agencies responsible for providing acceptance of the web services developed for MDOS will indicate

acceptance of the application through a written acceptance and sign‐off of the following project deliverables

based on the stage exits identified within the Systems Engineering Methodology (SEM).

• Requirements

• Design

• User Testing

• Implementation

PROJECT CONTROL AND REPORTS: A weekly progress report must be submitted to the Agency and DTMB Project Managers throughout the life of

Revised 4/7/2016

this project. This report may be submitted with the billing invoice. Each weekly progress report must contain the following:

• Hours: Indicate the number of hours expended during the past two weeks, and the cumulative total to date for the project. Also state whether the remaining hours are sufficient to complete the project.

• Accomplishments: Indicate what was worked on and what was completed during the current reporting period.

• Funds: Indicate the amount of funds expended during the current reporting period, and the cumulative total to date for the project.

• Next Steps: Identify what will be completed in the next two week reporting cycle

• Weekly Status Progress Report

• Identify Issues

LIQUIDATED DAMAGES: The parties acknowledge that late or improper completion of the Work will cause loss and damage to the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result. Therefore, Contractor and the State agree that if there is late or improper completion of the Work and the State does not elect to exercise its rights under Section 2.152 in contract #071B430022, the State is entitled to collect liquidated damages in the amount of $5,000.00 and an additional $100.00 per day for each day Contractor fails to remedy the late or improper completion of the Work. Unauthorized Removal of any Key Personnel It is acknowledged that an Unauthorized Removal will interfere with the timely and proper completion of the Contract, to the loss and damage of the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result of any Unauthorized Removal. Therefore, Contractor and the State agree that in the case of any Unauthorized Removal in respect of which the State does not elect to exercise its rights under Section 2.152, the State may assess liquidated damages against Contractor as specified below. For the Unauthorized Removal of any Key Personnel designated in the Contract or any Statement of Work issued under it, the liquidated damages amount is $25,000.00 per individual if the Contractor identifies a replacement approved by the State under Section 2.060 in contract #071B430022 assigns the replacement to the Project to shadow the Key Personnel who is leaving for a period of at least 30 days before the Key Personnel’s removal. If Contractor fails to assign a replacement to shadow the removed Key Personnel for at least 30 days, in addition to the $25,000.00 liquidated damages for an Unauthorized Removal, Contractor must pay the amount of $833.33 per day for each day of the 30 day shadow period that the replacement Key Personnel does not shadow the removed Key Personnel, up to $25,000.00 maximum per individual. The total liquidated damages

Revised 4/7/2016

that may be assessed per Unauthorized Removal and failure to provide 30 days of shadowing must not exceed $50,000.00 per individual. SPECIFIC DEPARTMENT STANDARDS: Agency standards, in addition to DTMB standards PAYMENT SCHEDULE:

Project work will begin upon receiving the purchase order and will be completed within eight weeks. Any RFCs

that impact scope may result in a longer duration.

Payment will be made on a satisfactory final acceptance at conclusion of the contract basis. DTMB will pay CONTRACTOR upon receipt of properly completed invoices which shall be submitted to the billing address on the State issued purchase order not more often than monthly. DTMB Contracts area will coordinate obtaining Agency Project Manager and DTMB Project Manager approvals. All invoices should reflect actual work completed by payment date, and must be approved by the Agency Project Manager and DTMB Project Manager prior to payment. The invoices shall describe and document to the State’s satisfaction a description of the work performed, the progress of the project, and fees. When expenses are invoiced, receipts will need to be provided along with a detailed breakdown of each type of expense. Payment shall be considered timely if made by the DTMB within forty‐five (45) days after receipt of properly completed invoices.

The KL&A payment address is:

Kunz, Leigh & Associates

P.O. Box 760187


Lathrup Village, MI 48076‐0187

COST/RATE:

This is a fixed‐price proposal for $13,450.

Table: Cost Breakdown

Functional Task Hours Rate Total

Restrict Requests Being Backdated 40 $90 $3,600.00

Ability to Backdate Suspended On 24 $90 $2,160.00

Show Warning if Suspending a Request When Completed 16 $90 $1,440.00

UAT, Documentation 20 $125 $2,500.00

Project Management 30 $125 $3,750.00

Totals 130 $13,450.00

Revised 4/7/2016

EXPENSES: The State will not pay for any travel expenses, including hotel, mileage, meals, parking, etc. PROJECT CONTACTS: The designated Agency Project Manager is: Lona Angel Michigan Department of State Secondary Complex, SOS Building 7064 Crowner Drive Lansing, MI 48918 517‐636‐4422 [email protected] The designated DTMB Project Manager is: Dan Klodt Michigan Department of Technology, Management and Budget 517‐636‐0234 Email: [email protected] The DTMB Contract Administrator for this project is: Terry Mead Michigan Department of Technology, Management and Budget DTMB Procurement 525 W. Allegan Street Lansing, MI 48933 517‐284‐7035 Email: [email protected] AGENCY RESPONSIBILITIES: Meet with vendor to describe needs and requirements of the project and review progress, will verify user acceptance testing, acceptance of completed tasks/deliverables. LOCATION OF WHERE THE WORK IS TO BE PERFORMED: Consultants will work at Secondary Complex, SOS Building, 7064 Crowner Drive, Lansing, Michigan.

EXPECTED CONTRACTOR WORK HOURS AND CONDITIONS: Work hours are not to exceed eight (8) hours a day, forty (40) hours a week. Normal working hours of 8:00 am to 5:00 pm are to be observed unless otherwise agreed to in writing. No overtime will be permitted.

Revised 4/7/2016




CO

NT

RA

CT

OR


ST

AT

E

Pro

gram

M

anag

er Susan Nordyke DTMB



John Leigh

Co

ntra

ct

Adm

inis

trat

or Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective September 19, 2016, this Contract is hereby increased by $79,255.00 to provide enhancements and upgrades to the Newborn Screening Online (NBSO) application. See attached Statement of Work dated August 26,


CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services MIRS rPS ARS










REVISED EXP. DATE

☐ ☐


$5,687,033.37 $79,255.00 $5,766,288.37

Revised 4/7/2016

2016. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor and agency agreement, and DTMB Procurement approval.


MANAGEMENT AND BUDGET

IT SERVICES

STATEMENT OF WORK

Project Title:

Newborn Screening Online Enhancements and Upgrades

Period of Coverage:

09/26/2016-09/30/2017

Requesting Department:

Michigan Department of Health and Human Services

Date:

8/26/2016

Agency Contract Administrator:

Janice Bach

Phone:

(517) 335-8497

DTMB Contract Administrator:

Kimberly Koppsch-Woods

Phone:

(517) 335-1653

This Attachment is made a part of Change Notice 9 to Contract No. 071B4300022 (Contract) between the State of Michigan (State or SOM) and Kunz, Leigh & Associates (KL&A or Contractor). The Parties agree as follows: 1. OVERVIEW AND DEFINITIONS

1.01 The recitals set forth above are incorporated into this Statement of Work (SOW).

1.02 All duties and obligations described herein will become part of existing Contract. All terms, conditions, and specifications contained in the existing Contract must remain in full force and effect.

1.03 “Days” means calendar day unless specifically stated otherwise in the Contract.

1.04 “DTMB” means the State of Michigan Department of Technology, Management and

Revised 4/7/2016

Budget.

1.05 “Good Faith” means honesty in fact and the observance of reasonable commercial standards of fair dealing.

1.06 “Implementation” means activities required to install the software, databases, and/or data that comprise the product onto the hardware platform. User training is included as part of an Implementations.

1.07 “Michigan Department of Community Health”, “Community Health”, and “DCH” in this SOW and the existing Contract mean the Michigan Department of Health and Human Services. Under the recently effectuated State Executive Order No. 2015–4, the entities formerly known as the separate Michigan Department of Community Health (“MDCH” or “DCH”) and the Michigan Department of Human Services (“MDHS” or “DHS”) have Doesn’t Section one department named the Michigan Department of Health and Human Services (“MDHHS” or “DHHS”).

1.08 “Operational” means system availability in the production environment.

1.09 “Project Management” means the Contractor’s obligation to facilitate communications between the State Contract Administrators, State personnel, and the Contractor personnel.

1.10 “Risk” means an unknown circumstance or event that, if it occurs, may have a positive or negative impact on the project and/or Contractor’s services and deliverables.

1.11 “Subcontractor” means any company or entity Contractor delegates performance of a portion of the services or deliverables to. Subcontractor is broadly defined to include any entity working to forward Contractor’s business. The term subcontractors does not include independent contractors engaged by Contractor solely in a staff augmentation role.

1.12 “Task” means a service and/or deliverable from the Contractor.

1.13 “Testing” includes creation and execution of a DTMB-approved Testing Plan. Testing, at a minimum, must include Unit, Integration, and UAT testing.

1.14 Any terms or concepts in this Work Request that are not defined in the Contract are governed by their plain meaning.

1.15 MDHHS requires that all infants born within the State of Michigan be administered a health

screening, ideally within 24-36 hours of their birth, for rare but treatable genetic disorders. Many of the medical concerns caused by genetic disorders are detected by Newborn Screening (NBS) system. MDHHS has requested that Contractor provide enhancements to the NBS Online (NBSO) application. The NBSO system areas that require functionality enhancement include, but are not limited to:

1) Fee Waiver Management. Contractor must enhance two waiver forms: Store Fee-

Revised 4/7/2016

Waiver and Validate Fee-Waiver. The Store Fee-Waiver allows users to run reports to view fee waiver forms. The validate Fee-Waiver form allows users to view WIC/Income requirements.

2) Admin Order Management. Admin orders provide users with the ability to manage orders by editing contents, deleting unneeded orders, and refunding orders before shipments are made to avoid returns and exchanges. This interface provides categorized information to assist users in returning and exchanging orders. In addition, this revised functionality will expedite order preparations by allowing users to email multiple addresses as needed.

3) Order/Inventory Management for Navigation and Sorting. This enhanced interface will provide additional organizational structure to allow users to sort information into categories and subcategories. This will allow users to more easily navigate lists of available items. In addition, this revised functionality will streamline inventory locations and search filtering tasks.

4) User/Customer Access Management. This enhanced interface will allow users to more easily remove customers, users, and email accounts from frontend listings.

5) Screening Cards. This enhanced interface will update import functionality streamline the NBSO card imports.

6) Inventory. This enhanced interface will provide new functionality for advanced unit of measure management for all inventory types (cards and non-cards).

7) Order Notes. Currently, users of the NBSO application do not have the functionality to add notes to orders. This is needed when users are on vacation, management of clients changes hands or in many other circumstances. Notes will be able to be viewed by SOM users and entered by all users.

1.16 As part of this project, Contractor must also provide the State with technical support to assist with application deployment (during testing and when moving to production) and database changes (by script during testing and when moving to production).

2. CONTRACTOR’S SCOPE OF RESPONSIBILITIES

2.01 Fee Waiver Management. Contractor must develop the Store Fee-Waiver Form data, which allows user to run reports to view fee waiver forms. The fee waiver will confirm whether individuals are eligible to have their NBS screening fee waived due to an inability to pay. Contractor’s services and deliverables include:

1) Validation of the Fee-Waiver form during submission for Women Infant Children Program (WIC) or low income requirements.

2) Development to store the details of each fee-waiver form submitted.

Revised 4/7/2016

3) Development to add report that lets NBSO program worker view the fee-waiver form for a specified order.

4) Development to add new interface to verify low income or WIC information entered on Fee-waiver form with data in CHAMPS via a one-way call to the CHAMPS web service.

5) Validation that will deny the fee-waiver request if they do not qualify as low income or WIC eligible.

6) Contractor must update or add the screens. These include, but are not limited to:

i. Adding the ability to store fee waiver form data. ii. Adding the ability for system users to run reports for fee waiver form data. iii. Updating a validation message that notifies user they have been denied based

on inaccurate low income or WIC information.

7) Contractor must update or add Fee Waiver functionality. These include, but are not limited to:

i. The reporting functionality. ii. Validation functionality to the Fee-waiver process for low income/WIC eligibility.

2.02 Admin Order Management. Contractor must update and add Admin Order Management screens, which provide users with the ability to sort orders (edit/delete contents and refund prior to shipping without return and exchange). These screens will allow the State to deleted unneeded orders. Contractor’s services and deliverables include:

1) Contractor must provide more detailed information displays for return and exchange orders. These include, but are not limited to:

i. Information that connects return and exchange (R & E) orders to the original order from which they are linked to.

ii. Information that details return and exchange type and details return and exchange process.

2) During order preparation, allow user to add multiple emails to Additional email address field.

3) Contractor’s development tasks include, but are not limited to:

i. Add ability for NBSO Admin user to edit the contents of an order after it has been placed.

ii. Add ability for NBSO Admin to delete/void an order after it has been placed, and before it is shipped.

Revised 4/7/2016

iii. Add ability for NBSO admin to issue a refund without shipping the item (a refund after deleting or voiding an order).

iv. Add ability for NBSO Admin to trace the origin of a return / exchange. Visible association between the original order and the return / refund / exchange.

v. Add more statuses to describe the type of return / refund / exchange completed. Add a new status type to stop statuses from being overwritten.

vi. Add ability for multiple emails to be added into the additional email address field.

4) Contractor must update and/or add Admin Order Management screens. These include the following tasks:

i. Order details screen to add options to void order, edit order, and issue refund. ii. Order details screen to display traceability and association between original

orders and replacement orders/refunds. iii. Order List screen to add new statuses to show an order that has been voided. iv. Place Order screen to allow multiple emails in additional email field. v. Reporting functionality to account for new statuses and traceability for

return/exchange orders. vi. Functionality on Order Details screen to add the ability to edit, issue refund prior

to shipping, and void order.

2.03 Order/Inventory Management for Navigation and Sorting. Contractor must update and/or add functionality to the user lists to create categories and subcategories for easier navigation and sorting. This function will allow the State to establish the current inventory, facilitate recalls on kit numbers, and map users to NBS cards for more efficient card and kit tracking management. Contractor’s services and deliverables include:

1) Contractor must perform development to:

i. Add Inventory Item attributes to the “Add/Edit Inventory Item” area to allow users to specify the category/sub category of an item.

ii. Add the ability of the Place Order Screen to navigate through the category/subcategory options and select the item.

iii. Update new categories to allow for subcategory data.

2) Contractor must update and/or add Order/Inventory screens. These include:

i. Add and edit the inventory item. ii. The “Place Order” screen.

3) Contractor must update and/or add functionality. This includes:

i. Add and update the Inventory Item functionality will be updated to add the new category/ subcategory attributes.

ii. Place Order screen will be updated to accommodate for the new category options.

Revised 4/7/2016

2.04 User/Customer Access Management. Contractor must update and/or add the ability to remove customers, users, and addresses from frontend listings so that users can change account email addresses. This function will allow the State to perform maintenance functions. Contractor’s services and deliverables include:

4) Contractor must perform development to add the following abilities:

i. Automatically remove customers, users, and addresses that go unused for a specified amount of time from frontend listings.

ii. Allow the State to manually archive a customer, user, and address from frontend listings.

iii. Allow State users to update their email address.

5) Contractor must update the existing User/Customer Management screens. These include:

i. Editing the Manage Users and Manage Customer screen to add the functionality to remove listings.

ii. Editing the Account screen to give State users the ability to edit their email address.

2.05 Screening Cards. Contractor must update the import functionality to NBS Screening Card processes. This function will allow the State to import non-sequential cares in one import run. Contractor’s services and deliverables include:

1) Development to add functionality for flexible card management (import).

2) Contractor must update and/or add Screening Card screens. These include, but are not limited to:

i. Import Card screen. ii. Manage Cards screen (to reflect the renovated import functionality).

3) Import Card functionality will be updated to allow more flexibility for adding screening cards to inventory.

2.06 Inventory. Contractor must update and/or add functionality for advanced unit of measure management for all inventory types (cards and non-cards). This functionality will allow State users to better gauge current supplies of materials, including cards, brochures, and home birth kits. Contractor’s services and deliverables include:

1) Contractor must perform development to add new attribute for grouping and ability to build a package or bundle for non-card items.

2) Contractor must update and/or add Inventory screens. These include, but are not limited to:

Revised 4/7/2016

i. Edit Inventory Item ii. Add Inventory Item iii. Manage Inventory Item

3) Contractor must update and/or add the Place Order functionality will be updated to process pricing for grouped items.

2.07 Order Notes. Contractor must update and/or add functionality for users to be able to enter notes based on specific orders for cards. Contractors services and deliverables include:

1) Contractor must perform development to allow users to enter notes and view notes entered by different users. This will be done on two different screens.

2) Contractor must update/change database to work properly with this new functionality.

3) Contractor must update two reports to show the notes that have been entered by users.

2.08 Monthly Progress Report for Each Project. A monthly Progress Report for each of the Projects described herein must be submitted to the DTMB and DHHS Contract Administrators throughout each Project term. Contractor must combine all Project Reports into a single document. The Report may be submitted with Contractor’s billing invoice.

2.09 Monthly Progress Report Details. Each monthly Progress Report must contain the following information:

1) Hours. Contractor must indicate the number of hours expended by resource name during the past month with a summary of activities, hours allocated to each effort, the cumulative total of hours expended to date for the Project, and confirmation of whether the remaining hours are sufficient to complete the Project.

2) Accomplishments. Contractor must state the tasks completed during the current month’s reporting period. These include, but are not limited to the following Monthly Progress Report items:

i. Reports on any application defects or errors ii. Issue and Resolution Log Report iii. Recommendations for application changes iv. Change Log Reports v. Defect Log Reports vi. Quality Management Report vii. Root Cause Analysis Report explaining the root cause of any and all

errors viii. Project Management Plan and Schedule

Revised 4/7/2016

3) Funds. Contractor must state the amount of funds expended during the current reporting period, and the cumulative total to date for the Project.

4) Projected Accomplishments. Contractor must describe the activities protected to be accomplished during the next month’s reporting period.

5) Issues. Contractor must describe any issues, risks, changes, real or perceived, and recommend resolutions.

2.10 Unless otherwise requested by the DTMB Contract Administrator, Contractor may name certain Reports from the above-named list as “not applicable” for a particular Project, as appropriate. Contractor must provide additional information for any named item upon the request of the DTMB Contract Administrator.

2.11 Quality Control Procedures. As part of a good faith efforts to comply with State SUITE requirements and satisfy all Contract requirements timely and accurately, Contractor will establish and maintain written Quality Control Procedures (“QC Procedures”). QC Procedures must be based on Contract requirements, including, but not limited to, the Statement of Work (“SOW”), project-level standards, benchmarks, and other protocols mutually determined between the State and Contractor. QC Procedures must incorporate the use of both automated and manual quality control tools so that the Contractor can continuously monitor the timeliness and accuracy of all billings, services, and deliverables to the State.

2.12 Updates to Quality Control Procedures. Contractor will deliver a copy of its QC Procedures to the DTMB and DHHS Contract Administrators within 30 days after this SOW becomes effective. Contractor must provide any updates or changes to QC Procedures to the DTMB and DHHS Contract Administrators no later than 30 days after the update or change is made.

2.13 Quality Assurance Review of All Deliverables. Contractor will ensure each Contract deliverable undergoes a thorough quality assurance review and approval process before its release to the State. These items include, but are not limited to, all testing, small projects process documents, billings, and correspondence. Contractor’s staff must thoroughly review all deliverable and service requests from the State to ensure all requirements were completed. Contractor’s Project Manager must perform a final quality control review and is ultimately responsible for the overall quality of all billings, recoupments, and deliverables.

2.14 Monthly Quality Management Report. Contractor’s Quality Management Report must contain a summary of each of Contractor’s quality assurance reviews during the previous month. Contractor’s Monthly Quality Management Report must measure Contractor’s overall quality performance levels and identify any reoccurring quality concerns. Contractor must submit its first Monthly Quality

2.15 Quality Issue Tracking. Contractor must document and track any quality issues that arise throughout the course of the Contract in the Quality Management Report. Contractor’s

Revised 4/7/2016

Project Manager must ensure that Contractor promptly resolves all quality control incidents. Contractor must also implement quality assurance procedures as needed to prevent reoccurring issues.

2.16 Training for Reoccurring Quality Concerns. Once Contractor and/or the State has identified a reoccurring quality concern that indicates a training need, Contractor must provide the necessary training to its personnel or subcontractors as soon as reasonably possible. Results from Contractor’s quality reports must be used to augment staff training for Contractor’s personnel

3. PROJECT SCHEDULE AND ESTIMATED RESOURCES

3.01 Contractor’s preliminary, high-level Project Schedule for this Project is estimated as follows:

Task Contractor’s Resource Title

Approximate Hours

Anticipated Start Date

(Month/Year)

9. Business Requirements

10. Gathering/JAD Sessions

Dev/PM/BA -- 09/26/2016

JAD Session Dev/PM/BA 4 09/26/2016

Requirements Gathering

Dev/PM/BA 20 09/30/2016

11. Documentation BA/PM -- 09/26/2016


BA/PM 5 10/4/2016


BA/PM 20 10/7/2016

Create Test Cases BA/PM 20 09/30/2016

12. System Development Dev/PM -- 10/3/2016

Fee Waiver Dev/PM 55 10/3/2016

Admin Order Management

Dev/PM 190 10/11/2016

Order Inventory Management

Dev/PM 110 11/7/2016

User/Customer Management

Dev/PM 30 11/28/2016

Screening Cards Dev/PM 55 12/5/2016

Inventory Dev/PM 55 12/13/2016

Revised 4/7/2016

Notes Dev/PM 110 12/23/2016

13. User Acceptance Testing Dev/PM/BA -- 1/10/2016

User Testing Dev/PM/BA 10 1/10/2016

User Testing Fixes Dev/PM/BA -- Unknown

User Testing Dev/PM/BA 10 1/27/2017

UAT Business Owner Write-Off

Dev/PM/BA 10 1/27/2017

14. Production Implementation

PM/BA -- 1/27/2017


PM/BA 30 1/27/2017

Implementation Meeting

PM/BA 8 1/31/2017



PM 4 2/3/2017

Submit RFC Document

PM 1 2/10/2017

Implementation PM 33 2/21/2017

Verification Testing Dev/PM 15 2/10/2017

Go-Live Business Owner Write-Off

PM 1 2/14/2017


4. SPECIFIC AGENCY STANDARDS

4.01 IT Security Requirements. Contractor must comply with all State Information Technology Security Policies, including but not limited to those listed within the existing Contract, herein, and on the DTMB “IT Policies, Standards, and Procedures (PSP)” webpage, currently found at http://michigan.gov/dtmb/0,4568,7-150-56355_56579_56755---,00.html.

4.02 If Contractor is unable to access or view any of the IT Security Requirements listed on any State website, Contractor must promptly notify the DTMB Contract Administrator, who will facilitate communications with the State Office of Cybersecurity & Infrastructure Protection. Contractor must ensure it is compliance with all State and federal policies and standards that may have security requirements or security impact on the project.

Revised 4/7/2016

4.03 Contractors must lead all efforts to identify all State and federal policies and standards that may have security requirements or security impact on the Project.

4.04 In the event Contractor identifies a State and federal policy and/or standard that may have security requirements or security impact on this Contract’s Project, Contractor must immediately notify the State.

5. TECHINICAL ASSUMPTIONS

5.01 This project will be developed with the Scrum (Agile) methodology, delivering functionality through a series of releases; each release will provide a project milestone.

5.02 Contractor will provide test cases and for user acceptance testing (UAT) prior to each release and will facilitate UAT.

5.03 UAT will be concluded within 5 business days of each Sprint release.

5.04 UAT test cases will be written and executed using Unified Functional Testing.

5.05 DTMB will be responsible for deploying the releases to production and the test server.

5.06 Contractor will use Github for source control and deliver source code with each release deployment.

6. PAYMENT SCHEDULE AND PRICING

6.01 Payment will be made on a firm fixed-hourly rate in accordance with the existing Contract.

6.02 Payment will be considered timely if made by the State within forty-five (45) days after receipt of properly completed invoices.

6.03 The total purchase price for Professional Services (estimated time and materials fees) for this SOW is $79,255.00. This total figure is made up of the following items:

Functional Enhancement Hours Rate Total

Fee Waiver 45 $90 $4,050.00

Admin Order Management 178 $90 $16,020.00

Order Inventory Management 100 $90 $9,000.00

Revised 4/7/2016

User/Customer Management 22 $90 $1,980.00

Screening Cards 45 $90 $4,050.00

Inventory 45 $90 $4,050.00

Notes 97 $90 $8,730.00

BA Hours 65 $100 $6,500.00

PM Hours 199 $125 $24,875.00

Totals 796 $79,255.00

6.04 All total charges are estimated. The State is under no obligation to utilize all estimated hours.

6.05 The State is under no obligation to utilize all of the hours estimated for onsite and remote work within this SOW and the existing Contract. This SOW does not constitute any commitment from the State to utilize additional Contractor services.

6.06 Any and all additional work effort or services funds not included in this Work Request must be pre-approved by the State DTMB Contract Administrator and follow the State’s established Project Change Request approval processes.

7. NOTICE AND PROJECT CONTACTS

7.01 The DHHS Contract Administrator is:

Janice Bach

MDHHS-NBSO

[email protected]

(517) 335-8497

7.02 The DTMB Contract Administrator is:

Revised 4/7/2016

Kimberly Koppsch-Woods Michigan Department of Technology, Management and Budget Agency Services Supporting Michigan Department of Health and Human Services Chandler Building 300 E. Michigan Ave., Ste. 2 Lansing, MI 48933 (517) 284-7156 [email protected]

8. HOURS AND LOCATION OF WHERE THE WORK IS TO BE PERFORMED

8.01 The work is to be performed, completed, and managed remotely unless otherwise determined by the Contractor and approved by the DTMB Contract Administrator.

8.02 Contractor personnel must be available, on hand, and able to complete emergency tasks.

8.03 The State is not obligated to provide State management of assigned work outside of normal State working hours. The State reserves the right to modify the work hours in the best interest of the project. Contractor(s) must observe the same standard holidays as State employees. The State does not compensate for holiday pay. Contractor(s) will not be reimbursed for travel expenses or travel time. No overtime will be permitted.

8.04 Contractor’s Location. The majority of Contractor’s work on this Project will occur at 2164 University Park Drive, Suite 200, Okemos, MI 44864.

8.05 Contractor’s Business Hours. Work hours are not to exceed eight (8) hours a day, forty (40) hours a week. Normal working hours of 8:00 am to 5:00 pm are to be observed unless otherwise agreed to in writing.

9. GENERAL PROVISIONS

9.01 Good Faith. Pursuant to existing Contract Section 2.028, each party must act reasonably and in good faith in performing duties and obligations under the Contract.

9.02 Satisfaction. Contractor must not consider any aspect of this Project to be complete until Contractor has received a written confirmation of satisfactory work from the DTMB Contract Administrator.

9.03 No Commitment for Additional Services. This SOW does not constitute a commitment by the State to utilize any additional services. Utilization of additional services funds requires pre-approval of the DTMB Contract Administrator and must follow and established Project Change Request approval process. Hours listed above for onsite and remote by resources may be adjusted by written approval of the State DTMB Contract Administrator.

Revised 4/7/2016

9.04 Compliance with State and Federal Law, Administrative Regulations, Guidelines, and Recommendations. Contractor must ensure the system complies with all Federal and State law, administrative regulations, guidelines, and recommended policies. These include, but are not limited to, items released from the Centers for Medicare and Medicaid Services (CMS), Internal Revenue Service (IRS), the National Institute of Standards and Technology (NIST), U.S. Office of Management and Budget (OMB), National Institutes of Health (NIH), and the Office for Civil Rights (“OCR”).

9.05 Web or Hyperlinks. In the event Organization is unable to access or view any of the web links (also known as hyperlinks) contained within this Agreement, Organization must promptly notify the DTMB Contract Administrator. An inaccessible or non-working web link will not excuse the Organization of its duties and obligations under this Agreement. Organization is responsible for ensuring its personnel and/or subcontractors have reviewed all State and DTMB policies under this Agreement.

9.06 Entire Agreement. This SOW, together with the existing Contract, constitutes the Parties’ complete and exclusive statement regarding work requirements and procedures. Apart from the amendments made in this SOW, all Contract terms and conditions must remain in full force and effect.

IN WITNESS WHEREOF, the Parties, intending to be legally bound, have caused their duly authorized officers to execute this SOW via a contract change notice signature page, which is incorporated herein by reference.

Revised 4/7/2016





CONTRACT SUMMARY




N/A







$5,284,033.37 $403,000.00 $5,687,033.37 DESCRIPTION

Effective August 30, 2016, this Contract is incresed by $403,000.00 and the following Statement of Work (SOW) is attached. All other terms, conditions, specifications, and pricing remain the same. Per Contractor and Agency agreement, DTMB Procurement approval and State Administrative Board approval on August 30, 2016.

ST

AT

E

Pro

gram

M

anag

er Susan Nordyke DTMB-IT

517-373-9784

[email protected]

Co

ntract

Ad

min

istrator

Terry Mead DTMB

(517) 284-7035

[email protected]

CO

NT

RA

CT

OR




John Leigh

517-202-4625

[email protected]

*******1652

Revised 5/4/2016


MANAGEMENT AND BUDGET AGENCY SERVICES SUPPORTING THE MICHIGAN DEPARTMENT OF HEALTH AND HUMAN SERVICES

CONTRACT CHANGE NOTICE STATEMENT OF WORK This Statement of Work (SOW) is made a part of Contract No. 071B4300022 (the “Contract”) between the State of Michigan (“State”) and The Kunz, Leigh &

Associates (“KL&A” or “Contractor”) effective as of the date set forth on the cover page of this Agreement. NOW THEREFORE, the Parties agree as follows:

I. Background

1. The SIGMA system will impact all areas of State business operations, from payroll and purchasing, to payment of suppliers, disbursement of grant funding and processing of unemployment, financial aid and child support. The system must interface with each of the applications managing these process areas, as well as those utilized for payment processing and revenue generating applications. To successfully implement the required functionality and realize projected efficiencies of SIGMA, the interfaces must be in established, tested and fully implemented. The State does not have resources with the necessary technical ability and bandwidth to accomplish the transition independently. Thus contract change notices will be processed for those interfaces which can be managed through existing contracts and staff augmentation resources will be obtained through bids completed under the pre-qualification program.

2. The SIGMA project extension impacts the MiCaRS project schedule and budget.

a. Schedule Amendment. The schedule requires an increase of 8 months. b. Budget Impact. The total budget requires an increase of $403,000 across all agencies. MDHHS, MSP, MDOT, and MDOS require additional

funding. The cost for each agency is $100,750.

II. Environment / IT Standards

III. Project Objective

1. The SIGMA project has extended their project timeline, more specifically the test timeline has grown substantially. The former MiCaRS project timeline did not include the required resources to support the new SIGMA project timeline. KL&A must successfully design and implement necessary interfaces between existing systems and SIGMA for continued and improved operations and business processes throughout the state.

IV. Scope of Work

Revised 4/7/2016

a. Deliverables

List specific interface(s) to be covered by this change request (provide task detail in table below):

1. The purpose of this change request is to increase the project timeline for the MiCaRS for SIGMA project as a result of the SIGMA project timeline expansion. The change will impact the MiCaRS for SIGMA schedule and budget. No new resource staff will be added.

2. The SIGMA team communicated their change in schedule on 10/19/2015 via a schedule timeline. The timeline, when compared to the original SIGMA timeline, included an increase in schedule duration for a number of the project phases, most notably the timelines for System and User testing had increased.

3. The KL&A MiCaRS team used the new SIGMA timeline to perform a schedule impact analysis. The analysis began by reviewing the original SIGMA project

timeline and the MiCaRS project timeline. Please note that neither of the SIGMA project timelines provided much detail. The original MiCaRS timeline was (a viewable of the timeline is on a separate page below):

5/1/2015 12/31/2016Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Sep ‐ Sep

Cut‐over.5 months

Feb ‐ Apr

System Testing2.5 months

Oct ‐ Dec

Post Production Support3 months

May ‐ Jun

Impact Analysis & Design2 months

Jun ‐ Feb

Development & Unit Test8.5 months

May ‐ Sep

User Testing4.5 months

4. The original MiCaRS resource distribution was:

Development and Unit Testing

4 resources for 8.5 months

3 resources for 3 months

System Testing 7 resources for 2.5 months

User Testing 4 resources for 4.5

months 3 resources for 3.5

months

Cut-over 4 resources for 0.5 months

5. The original MiCaRS timeline and resource distribution was developed using the original SIGMA timeline and draft documentation provided by the SIGMA

Revised 4/7/2016

project. From those artifacts, the KL&A team developed a Statement of Work (SOW) which included the above timeline and resource distribution.

6. The first major milestone for the MiCaRS project team was to produce, review, and approve an impact analysis of SIGMA functionality on MiCaRS. Joint Application Design (JAD) sessions were performed and included participants from each of the agencies. The result of the JAD sessions was an Impact Analysis document created by the KL&A team and reviewed by the State of Michigan team. The Impact Analysis resulted in no major changes to the original timeline and resulted in no change requests. The MiCaRS team then completed development, review and approval of a Requirements document and Design document. Neither resulted in change requests.

7. The MiCaRS for SIGMA development effort was scheduled to begin when the new SIGMA timeline was released. Therefore, the schedule impact analysis

performed by KL&A only includes Development and Unit Testing forward. The analysis revealed increases in each of the remaining project phases. As noted above, the most notable increases in the project timeline are in System Testing and User Testing. The new MiCaRS timeline is (a viewable of the timeline is below):

5/1/2015 12/31/2017Jul‐15 Oct‐15 Jan‐16 Apr‐16 Jul‐16 Oct‐16 Jan‐17 Apr‐17 Jul‐17 Oct‐17

Jun ‐ Nov

Design4 months

2 month slip

Dec ‐ Oct

Development & Unit Test10 months

1.5 month slip

Aug ‐ Feb

System Testing7 months

4.5 month slip

Mar ‐ Aug

User Testing6 months

1.5 month slip

Sep ‐ Sep

Cut‐over1 month

Oct ‐ Dec


May ‐ Aug

Impact Analysis4 months

2 month slip

8. The new Resource distribution is:

Development and Unit Testing 4 Developer resources for

10.5 months o Increase of 1.5

months 3 Developer resources for

3 months

System Testing 4 resources for 7 months (2 Developers, 2

Business Analysts) o Increase of 4.5 months

3 Business Analyst resources for 2.5 months

User Testing 4 resources for 6 months

(2 Developers, 2 Business Analysts)

o Increase of 1.5 months

Cut-over 4 Developer resources for 1 months

Revised 4/7/2016

3 resources for 3.5 months (1 Developers, 2 Business Analysts)

9. After reviewing the results of the schedule impact analysis, KL&A is requesting an increase in the timelines of work for 4 resources for a duration of 6

months. The 1.5-month increase in duration for Development and Unit Testing will be absorbed by KL&A as well as the .5 month increase in the Cut-over period.

10. Original MiCaRS for SIGMA Schedule

5/1/2015 12/31/2016Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Sep ‐ Sep

Cut‐over.5 months

Feb ‐ Apr

System Testing2.5 months

Oct ‐ Dec


May ‐ Jun

Impact Analysis & Design2 months

Jun ‐ Feb

Development & Unit Test8.5 months

May ‐ Sep

User Testing4.5 months

11. New MiCaRS for SIGMA Schedule

5/1/2015 12/31/2017Jul‐15 Oct‐15 Jan‐16 Apr‐16 Jul‐16 Oct‐16 Jan‐17 Apr‐17 Jul‐17 Oct‐17

Jun ‐ Nov

Design4 months

2 month slip

Dec ‐ Oct

Development & Unit Test10 months

1.5 month slip

Aug ‐ Feb

System Testing7 months

4.5 month slip

Mar ‐ Aug

User Testing6 months

1.5 month slip

Sep ‐ Sep

Cut‐over1 month

Oct ‐ Dec


May ‐ Aug

Impact Analysis4 months

2 month slip

V. Terms and Conditions

Revised 4/7/2016

1. Were agreed upon in the signed Contract or issued PO, they are not modified with every Change Notice. There should be no terms and conditions attached

to the Change requests in iTRAC, only this SOW document with a completed and approved iTRAC request. 2. This SOW, together with the existing Contract, constitutes the Parties’ complete and exclusive statement regarding work requirements and procedures.

Apart from the amendments made in this SOW, all Contract terms and conditions must remain in full force and effect. The Parties reserve all rights and remedies under the existing Contract.

IN WITNESS WHEREOF, the Parties, intending to be legally bound, have caused their duly authorized officers to execute this Agreement via a contract change notice signature page, which is incorporated herein by reference.

Attachment 1 Project Plan:

Tasks & Deliverables

Requirements Anticipated Completion

Date

Contractor Staff

Role Hours Rate Total Acceptance / Signoff Total Payment

Milestone I Requirements Gathering

Deliverable: Requirements Traceability Matrix. Design Plan. Detailed Design Docs.

10/20/2015 Meet with agency SME’s to establish interface requirements

Review Design Plan, State PM & Program Manager sign off after edits incorporated and final is accepted.

Task I Define Content (create RTM)

Lead Requirements Gathering

State PM & Program Manager

Task II Define Timeline

Training, Change Management


Task III Milestone Acceptance & Signoff


Milestone II Design the Interface

Design interfaces State PM & Program Manager

Task Program Interfaces State PM & Program

Revised 4/7/2016



Date

Contractor Staff


Program

Manager

Task II Test

Configure System modifications


Task III Resolve Defects




Milestone III Go Live


Task I Support/ Maintenance




Monthly Bill MDHHS

Flat bill October 2016 to October 2017 ($8,395 per month)

Business Analyst Project Manager Developer

Work completed by contract resources through the life of the project

959.52381

$105 $100,750 State PM & Program Manager

$100,750

Monthly Bill MDOS

Flat bill October 2016 to October 2017 ($8,395 per month)



959.52381


$100,750

Monthly Bill MDOT Flat bill October 2016 to October 2017 ($8,395 per month)



959.52381


$100,750

Revised 4/7/2016



Date

Contractor Staff


Monthly Bill MSP Flat bill October 2016 to October 2017 ($8,395 per month)



959.52381


$100,750

Totals

3836.09524


$403,000

Revised 5/4/2016




CO

NT

RA

CT

OR


ST

AT

E

Pro

gram

M

anag

er Susan Nordyke

DTMB



John Leigh

Co

ntra

ct

Adm

inis

trat

or

Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective July 29, 2016, this Contract is hereby increased by $78,040.00 to provide enhancements and update the Administrative Module of the Michigan State Police Payment Processing Center. These process improvements will increase manual labor efficiency as well as update the look and feel of the application. See KL&A Proposal dated July 28, 2016, attached. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor (request/proposal) and agency agreement, and DTMB Procurement approval.


CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services MIRS RPS ARS










REVISED EXP. DATE

☐ ☐


$5,205,993.37 $ 78,040.00 $5,284,033.37

Revised 4/7/2016

Statement of Work

Michigan State Police Payment Processing Center

Business Efficiency Updates

Preparedfor:

MichiganStatePolice

Preparedby:

Kunz,Leigh&Associates28081SouthfieldRoad

LathrupVillage,MI48076‐2816

July28,2016

Revised 4/7/2016

Objective......................................................................................................................................................37Scope.............................................................................................................................................................37Abilitytodeletequestions..............................................................................................................37Updating/EnhancingQuestionFilter.........................................................................................37MiCaRSIntegration............................................................................................................................37HistoryTable–Whodidwhat?....................................................................................................37ReportFix/DataDump.....................................................................................................................37SpecialCodeDynamicQuestions.................................................................................................38CharacterLimit....................................................................................................................................38Conference/CourseWebServiceChange.................................................................................38UserInterfaceUpgrade....................................................................................................................38

Assumptions..............................................................................................................................................38Schedule......................................................................................................................................................38Deliverables...............................................................................................................................................39Pricing..........................................................................................................................................................40

Revised 4/7/2016

Objective TheMichiganDepartmentofStatePolice(MSP)invoicesandcollectsfeesforanumberofservicesprovidedbythedepartmenttogovernmentalagenciesandindividuals.MichiganStatePolicePaymentProcessingCenter(PPC)isawebbasedapplicationdevelopedforprocessingpaymentinformationgeneratedfromcourse/conferenceregistrationinMI‐TRAIN.Afteritsinitialimplementationanumberofbusinessefficiencyupdateshavebeenidentified.Theseprocessimprovementswillincreasemanuallaborefficiencyaswellasupdatethelookandfeeloftheapplication.Below,youwillfindadetailedexplanationofeachtask.

Scope

Ability to delete questions Userneedstheabilitytodeletequestionsfromthequestionbank. Abilitytodeletewillonlybetheownerofthequestion.

Updating/Enhancing Question Filter Whenfilteringforspecificquestions,youcanonlydoitbyowner.Filteringneedsto

beaddedandupdatedtoallowamorespecificreturnonsearches. Thiswouldincludeafilterforquestiontextandinvoicedetaildescriptiontext.This

wouldbeasearchonthesetwofieldsandwouldallowtheusertosearchforanythinginthatfield.

MiCaRS Integration SystemwillautomaticallyupdateMSPMiCaRStosendoutaninvoicetotheclient. SystemwillverifyIndexandPCA. NotifyadministratoroffinancebyemailthatJV’shavebeencreated.The

administratorwillbeselectedbythePPCGroup.Thiscanbeoneormultiplepeople. UpdatePPCwhenanJVhasbeenfulfilledandverified. AdjustmentsmadeinMiCaRSneedtoupdatePPCwiththecorrectinformation.

History Table – Who did what? Currently,informationissavedonwhocreatesandmodifiesrecordsbutitisonly

displayedonafewpages.Whereneeded,throughouttheapplication,theuserswouldliketoseethisinformation.

Updatepagesthatareidentifiedinwhichtheycanshowthisinformation

Report Fix/Data Dump Thereport/datadumpneedtohavefieldsadded.Thesefieldsincludespecialcode

andquestion.Thiswouldincludeallquestionsandspecialcodesthatareassociatedtothedatadumped.

Revised 4/7/2016

Datadumpneedstoincludealldata,insteadofmostfields.

Special Code Dynamic Questions Usersneedtohavetheabilitytoenter/editspecialcodequestionswhenswitching

fromaninvoiceorcreditcardtospecialcodes.

Character Limit Acharacterlimitneedstobeaddedtotheregistrationsection.Rightnowitdoesnot

alerttheuserwhenthelimitismetorbeyond.

Conference/Course Web Service Change Anewwebservicewillneedtobeaddedtotheapplication. Adjustwebservicecallstoallowforfasterpageloadtimes. Adjustapplicationtoworkwiththenewwebservice.

User Interface Upgrade Currently,theapplicationisonlyusingstandardcssfortheuserinterface.Wewill

beupgradingtheuserinterfacetonowuseBootstrapwhichisuserinterfaceframeworklibrary.Thiswillallowustostandardizethelookandfeelaswellasupgradeit.

Assumptions TimelyDTMBresourceswillbeavailableforwebapplicationdeploysanddatabase

updates. UserswillbeavailableforUserAcceptanceTesting. AlldependentwebserviceswillbeavailablebyAugust15,2016inUAT. AlldependentwebserviceswillbeavailablebySeptember15,2016inProduction. AllchangesmadeforwebservicesaredependentuponcompletionbyKMIand

productionimplementation.

Schedule DevelopmentworkwillbeginonapprovalofStatementofWork. UATwillbescheduledandcompletedonaper‐modulebasis.

Task Contractor’s

Resource Title Approximate Hours

Anticipated Start Date (Month/Year)

17. Documentation BA/PM -- 09/01/2016


BA/PM 8 09/01/2016


BA/PM 22 09/02/2016

Revised 4/7/2016

Create Test Cases BA/PM 22 09/06/2016 18. System Development Dev/PM -- 09/01/2016

Ability to delete questions

Dev/PM 20 09/01/2016

Updating/Enhancing Question Filter

Dev/PM 20 09/02/2016

MiCaRS Integration Dev/PM 123 09/05/2016 History Table – Who did what?

Dev/PM 54 09/09/2016

Report Fix/Data Dump Dev/PM 34 09/13/2016 Special Code Dynamic Questions

Dev/PM 14 09/14/2016

Character Limit Dev/PM 14 09/15/2016 Conference/Course Web Service Change

Dev/PM 62 09/16/2016

User Interface Upgrade

Dev/PM 290 09/21/2016

19. User Acceptance Testing Dev/PM/BA -- Ongoing

User Testing Dev/PM/BA 10 -------------- User Testing Fixes Dev/PM/BA -- Unknown User Testing Dev/PM/BA 10 -------------- UAT Business Owner Write-Off

Dev/PM/BA 1 09/29/2016

20. Production Implementation

PM/BA -- 09/07/2016


PM/BA 15 09/07/2016

Implementation Meeting

PM/BA 8 09/09/2016



PM 4 09/10/2016

Submit RFC Document

PM 1 09/10/2016

Implementation Dev/PM/BA 40 09/20/2016 Verification Testing Dev/PM 15 09/26/2016 Go-Live Business Owner Write-Off

PM 1 09/29/2016


Deliverables Updatedwebapplication(UserAcceptanceandProductionBuild) Updatedusermanual. FacilitatedUserAcceptanceTesting Updatedfunctionaldesigndocument

Revised 4/7/2016

Specific Department Standards Agency standards, if any, in addition to DTMB standards

Pricing Afixedpricemodelof$78,040.00isproposed,brokendownbyfunctionaltasksbelow:FunctionalTask Hours Rate TotalAbilitytodeletequestions 20 $90 $1,800.00Updating/EnhancingQuestionFilter 20 $90 $1,800.00MiCaRSIntegration 123 $90 $11,070.00

HistoryTable–Whodidwhat? 54 $90 $4,860.00ReportFix/DataDump 34 $90 $3,060.00SpecialCodeDynamicQuestions 14 $90 $1,260.00CharacterLimit 14 $90 $1,260.00Conference/CourseWebServiceChange 62 $90 $5,580.00UserInterfaceUpgrade 290 $90 $26,100.00UAT,Documentation 80 $125 $10,000.00ProjectManagement 90 $125 $11,250.00 Totals 801 $78,040.00

Payment Schedule PaymentwillbemadeonasatisfactoryFinalAcceptanceattheconclusion.DTMBwillpayContractoruponreceiptofproperlycompletedinvoiceswhichshallbesubmittedtothebillingaddressontheStateissuedpurchaseordernotmoreoftenthanmonthly.DTMBContractsareawillcoordinateobtainingAgencyProjectManagerandDTMBProjectManagerApprovals.Allinvoicesshouldreflectactualworkcompletedbythepaymentdate,andmustbeapprovedbytheAgencyProjectManagerandtheDTMBProjectManagerpriortopayment.TheinvoicesshalldescribeanddocumenttotheState’ssatisfactionadescriptionoftheworkperformed,theprogressoftheproject,andfees.Whenexpensesareinvoiced,receiptswillneedtobeprovidedalongwithadetailedbreakdownofeachtypeofexpense.PaymentshallbeconsideredtimelyifmadebyDTMBwithin45daysafterreceiptofproperlycompletedinvoices.

Expenses TheStatewillnotpayforanytravelexpenses,includinghotel,mileage,meals,parking,etc.Noovertimewillbepermitted

Revised 4/7/2016




CO

NT

RA

CT

OR


ST

AT

E

Pro

gram

M

anag

er Nordyke, Susan DTMB



John Leigh C

ont

ract

Adm

inis

trat

or Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective July 12, 2016, this Contract is hereby increased by $103,800.00 to develop an interface to send cash receipts information from MiCARS to Accela and to receive accounts receivable data from Accela. See KL&A Proposal V 2.2 dated July 13, 2016, attached. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor (request/proposal) and agency agreement, and DTMB Procurement approval and the approval of the State Board on July 12, 2016.


CONTRACT SUMMARY











REVISED EXP. DATE

☐ ☐


$5,102,193.37 $103,800.00 $5,205,993.37


P.O. Box 760187



Phone: (248) 559‐7910

Fax: (248) 559‐8066

kunzleigh.com

Michigan Department of Transportation Attn: David Bruce 525 W Allegan Street. PO Box 30017 Lansing, MI 48909 Re: Accela Inc. Interface Proposal

Dear David Bruce,

Kunz, Leigh and Associates (KL&A) is pleased to propose application development services which will allow

Accela Inc. to access pertinent information regarding the Michigan Department of Agriculture and Rural

Development (MDARD) license records. This information will be used to update license records within the

Accela Inc. application database to payments made and recorded within the Michigan Cashiering and

Receivable System (MiCaRS).

KL&A proposes an 11 week schedule. To accomplish this timeline, KL&A intends to allocate to the project one

and a half full‐time Developers, one Project Manager and one Business Analyst. The total cost for the project

will be $103,800.

The attached proposal explains the approach we will take to develop the application, the scope of the project,

project assumptions, the roles required for this project and the responsibilities of each role, a project

schedule, a list of deliverables, the fixed‐price bid for this project, and a payment schedule.

If you have any questions, please contact John Leigh at 517‐202‐4625.

Sincerely,

John Leigh

KL&A Partner

Accela Inc. Interfaces

o Prepared for:

Michigan Department of Agriculture and Rural

Development525 W Allegan Street

PO Box 30017Lansing, MI 48909

o

o

o

o Prepared by:

o




V2.2 July 13, 2016

©Error! Unknown document property name. Kunz, Leigh & Associates 45

Proposal Signatures

P a g e | 46


KL&A v2.2 47

Table of Contents

1.0 Objectives ...................................................................................................................................... 49

1.1 Cash Receipt Tracking .............................................................................................................. 49

1.1.1 Receipt Tracking Use Case ............................................................................................... 49

1.2 Accrual Receivables Tracking .................................................................................................. 51

1.2.1 Design Considerations ..................................................................................................... 53

1.2.2 Receivable Use Cases ...................................................................................................... 53

2.0 Project Approach ........................................................................................................................... 54

3.0 Scope .............................................................................................................................................. 56

3.1 MiCaRS Front‐End Changes ..................................................................................................... 57

3.2 MiCaRS Web Service Interfaces .............................................................................................. 57

3.2.1 Multiple Check Inquiry .................................................................................................... 57

3.2.2 Single Check Inquiry ........................................................................................................ 58

3.3 Reference Data Web Services ................................................................................................. 59

3.3.1 List Reference Data ......................................................................................................... 59

3.3.2 Add Reference Data ........................................................................................................ 59

3.3.3 Delete Reference Data .................................................................................................... 60

3.4 Establish or Update Accela Receivable .................................................................................... 60

3.5 Zero Accela Receivable ............................................................................................................ 61

4.0 Assumptions ................................................................................................................................... 61

5.0 Roles and Responsibilities .............................................................................................................. 62

6.0 Schedule ......................................................................................................................................... 63

6.1 Schedule Detail ........................................................................................................................ 63

7.0 Deliverables ................................................................................................................................... 64

8.0 Cost ................................................................................................................................................ 64

9.0 Payment Schedule ......................................................................................................................... 66

9.1 Payment Address ..................................................................................................................... 66

List of Tables

Table 1. Project Assumptions ............................................................................................................... 61 Table 2. Roles and Responsibilities....................................................................................................... 62 Table 3. Deliverables ............................................................................................................................ 64 Table 4. Cost Breakdown ...................................................................................................................... 64

Contents

KL&A v2.2 48


1.0 Objectives The Michigan Department of Agriculture and Rural Development in conjunction with Accela Inc. is in

need of integration with MiCaRS. There are two main objectives: tracking cash receipts and establishing

accrual based receivables. Both these interactions need to work with MAIN and later SIGMA (once

SIGMA is in production).

1.1 Cash Receipt Tracking When a cash payment is processed in MiCaRS that needs to be linked to a service that is tracked in

Accela, for instance inspections, the cashier will be responsible for keying this reference data on the

batch entry screen.

In order for the reference data to be shared with Accela and MiCaRS, KLA will develop incoming web

service interfaces that will allow Accela Inc. to access payment information as well as update data on

their database. Also, changes will need to be made to the MiCaRS database and MiCaRS application,

which will allow the data to be processed correctly.

The diagram on the next page descriptions an example workflow showing the interaction between

Accela Inc. and MiCaRS with new functionality highlighted in green.

1.1.1 Receipt Tracking Use Case

1. Inspector is on site at a nursery and issues a request for payment, the inspection number is

provided on the supporting documentation to the customer.

2. Customer writes a check for $100 and writes the inspection number 1234 on the check.

3. Inspector logs the inspection number in Accela.

4. Accela System calls the "Maintain Reference Data" service to add the inspection number to the

MiCaRS reference tables.

5. MiCaRS Cashier receives check and sees that it is for an MDARD inspection, when deposit is

entered the Cashier is able to select the appropriate inspection number from the drop down

populated with the reference data.

6. Accela System calls the "Get Checks" Web Service to check on any Accela related revenue,

Accela notices that a check for $100 was received and the reference data is for inspection

number 1234.

7. Accela System marks the inspection as paid.

Rev 6/2015

Rev 6/2015

1.2 Accrual Receivables Tracking

When accrual based receivables need to be established with the Michigan Department of Treasury,

Accela will use MiCaRS to establish these receivables. Accela will be responsible for providing the

necessary invoice information to MiCaRS so that MiCaRS can establish the receivable and link Accela

invoice numbers to MiCaRS invoice numbers as outlined in the figure below:

Rev 6/2015

Check with MiCARS Invoice #

Establish Receivable

Accela

Create Accela

Invoice or Forgive Debt

MDARD Worker

Cashier

Update Invoice

Update MiCaRS Invoice

Create Accela

Receivable

MiCaRS MAIN

Update Receivable

Establish Receivable

Update Receivable

Log Payment against

Fee Record

Balance Changes

(CEPAS or correction)

Store Accela Invoice # on

MiCaRS Invoice

Accela Invoice Linking Process

MiCaRS tracks and links Accela receivables to MiCaRS Invoice Numbers

Accela Invoice #and Details

Accela Invoice #Line Items (Fee Type/Amount)

Generate and Mail

Delinquency Letter

(30,60,90)

30,60,90 Days and still open?

System will update

document to include

Accela Invoice #

Balance Changes

(CEPAS or correction)

Rev 6/2015

1.2.1 Design Considerations

In the situation where a cash receipt is received that is not linked to a MiCaRS invoice and an

Accela initiated receivable has already been created double revenue will be present until Accela

queries MiCaRS and updates receivable in MiCaRS.

Currently multiple programs are set up in RPS that are used to create MDARD invoices. For

Accela initiated receivables the MiCaRS invoice will be created under an “Accela” program,

which will be configured in MiCaRS with all possible accounting codes available. When an

invoice is created via the web service MiCaRS will crosswalk the SKU provided for each line to

the appropriate ratio of account codes and will use these account codes to create the line items

for the invoice.

1.2.2 Receivable Use Cases

Establishing Receivable

Accela System creates an accrual based receivable.

Accela System calls the "Create Accela Receivable" web service on MiCaRS, providing the Accela

invoice number, fee type and line items with amounts.

Accela System updates reference data associated with the receivable number with Accela

receivable number.

MiCaRS creates a MiCaRS invoice and links the Accela invoice number to the MiCaRS invoice

number

MiCaRS uses Accela customer id provided to link to existing customer if possible; otherwise, a

new customer is created with provided information and record number.

MiCaRS establishes receivable in MAIN.

After delinquency timeline MiCaRS AR worker generates invoice and letter.

Check with Accela Inspection # is received

MiCaRS Cashier types inspection number, MiCaRS displays the MiCaRS invoice number

associated with inspection number and the cashier links deposit to invoice and updates

receivable in MAIN.

MiCaRS updates document reference number with Accela Invoice # so that Accela can mark

receivable paid.

Check with a MiCaRS invoice # is received

MiCaRS Cashier links deposit to invoice and updates receivable in MAIN.

Rev 6/2015

MiCaRS updates document reference number with Accela Invoice # so that Accela can mark

receivable paid.

Customer pays via CEPAS

Customer logs onto CEPAS and pays the fine.

Accela System zeroes out receivable.

Accela System calls MiCaRS web service to set amount to zero.

MiCaRS updates receivable amount in MAIN.

If debt is forgiven:

Accela System zeroes out receivable.

Accela System calls MiCaRS web service to set amount to zero.


Establishing Receivable Use Case Executes.

If a partial payment is made in Accela.

Accela System updates receivable details.

Accela System calls MiCaRS web service to update receivable.


2.0 Project Approach The approach used for a project is an important part of a project’s success. A project will have a better

opportunity of success if it has the required funding, skilled resources, executive support, limited

impediments, and limited constraints. However, a project can have all of the right ingredients, but still

fail, if the project does not have a clear project approach.

The State of Michigan has addressed the need for a clear project approach by providing projects with a

framework, the State Unified Information Technology Environment (SUITE), which provides documented

methodologies for project management and systems engineering.

“The overall purpose of SUITE is to bring the Department of Technology,

Management & Budget (DTMB) systems development areas up to CMMI Level 3,

which ensures consistent process usage throughout the organization. This includes

using the same Project Management Methodology (PMM), Systems Engineering

Methodology (SEM), Process Management, and Supporting Processes across all

systems development areas within DTMB. The overall goal of SUITE is to integrate

Rev 6/2015

Project Management, Systems Engineering, Process Management, and Supporting

Processes into a single unified environment.”

SUITE does not dictate a finite list of activities for a project, but rather a framework for which to find the

best operating environment for a project team. The changes made to MiCaRS and its database will

adhere to SUITE, producing the required documentation with the PMM and SEM document templates.

The project will integrate the SUITE requirements into the system development life cycle (SDLC) by

following the SUITE PMM/SEM Integration for Agile, with the Scrum Framework as the Agile derivative.

Rather than having one nine‐week long SDLC, ending in release of the entire system, we will conduct

two‐week Sprints that encompass all phases of the SDLC, releasing one or more software features at the

end of each Sprint. This approach allows us to deliver functional software earlier in the project lifecycle,

which allows users to use the software and provide feedback that can be acted upon in the next Sprint.

The following illustration depicts the Scrum iterations, showing how each Sprint encompasses all SDLC

phases, beginning with requirements analysis through testing to product deployment.


Rev 6/2015

3.0 Scope The proposed solution involves creating a way for MiCaRS and Accela Inc. to transfer license and other

metadata information, which will allow Accela Inc. to track the payment status of the metadata against

revenue in MiCaRS. CEPAS payments are out of scope as Accela Inc. uses the CEPAS/SKU system for

tracking these payments and the revenue is never processed by MiCaRS.

The Accela Inc. system needs to maintain metadata, such as inspection numbers in the MiCaRS system

so that cashiers can link the metadata and receivable information to incoming checks. Metadata can

be linked to specific hotkeys to ensure the metadata will only be shown during appropriate check

data entry.

Cashiers need to be able to view Accela Inc. metadata information while entering a new check to help

with validation and verification through a type‐ahead.

The MiCARS administrator needs the ability to maintain the Accela Inc. metadata, via the MiCaRS user

interface, in order to ensure data integrity.

The MiCaRS administrator needs the ability to maintain SKU to program code information for Accela Inc.

receivables.

The Accela Inc. system needs to query the MiCaRS system with the ability to pull the following functional

information:

Documents that have been linked to Accela Inc. metadata.

Documents that are associated with Accela Inc. related hotkeys, regardless if they are linked with

Accela Inc. metadata.

Documents by control number.

Documents by date sent to MAIN.

The Accela Inc. system needs to establish, edit and zero out receivables in MiCaRS.

Rev 6/2015

3.1 MiCaRS Front‐End Changes Add lookup table for maintaining external systems and linking hotkeys to external systems.

Add lookup table for maintaining external system metadata.

Update the batch entry screen so that a MiCaRS user can see Accela Inc. metadata when adding a check

and typing meta‐data into the interface fields.

Update the batch entry screen so that if the metadata from Accela is also linked to an Accela receivable

number and linked to a MiCaRS invoice number the cashier can then link the receipt to the MiCaRS

invoice.

Display the metadata for validation and verification uses. The validation will use the table created in

MiCaRS and maintained by Accela Inc. to validate metadata.

3.2 MiCaRS Web Service Interfaces

All web services will be implemented as REST based services with JSON input and output.

3.2.1 Multiple Check Inquiry

A MiCaRS web service will be developed and exposed for external systems to call. The method,

getUndistributedChecks, will provide the external system with MiCaRS check information that is

currently allocated to their specific hotkey.

Query Criteria:

System key (required)

MAIN date range (required)

Web Service Rules:

Check was sent to MAIN between the dates provided. This will allow a control number to be sent to a

new system when the money is moved from one hotkey to another as well as metadata associated

with the check.

Check amount <> $0

Document amount > $0

Rev 6/2015

Data Elements Returned:

MiCaRS control number

MiCaRS entry number

Index/PCA/Object

Hotkey

Departmental object

Deposit number

Deposit suffix

Deposit date

Remit name

Document amount

Check number

External system metadata

3.2.2 Single Check Inquiry

The MiCaRS web service will contain a method to return the current distribution of a specific Control

Number. The method, getCheck, will provide the external system with distribution of the MiCaRS check

information, which was allocated using a specific hotkey. The result set will consist of two datasets, the

Control Number header and accounting line details.

Query Criteria:

System key (required)

Control number (required)

Web Service Rules:

Control number exists in MiCaRS

Check amount <> $0

At least one document was allocated to the system Key (even if the amount is $0 now)

Rev 6/2015


MiCaRS control number

MiCaRS entry number

Index/PCA/Object

Hotkey

Departmental object

Deposit number

Deposit suffix

Deposit date

Remit name

Document amount

Check number

External system metadata

3.3 Reference Data Web Services

These web services allow for manipulation of external system metadata.

3.3.1 List Reference Data

Query Criteria:

System Key


List of:

MiCaRS record key (unique)

Reference data elements (system key, notes, amount, etc.)

3.3.2 Add Reference Data

Query Criteria:

System key

Reference data elements (system key, notes, amount, receivable number, etc.)

Rev 6/2015



3.3.3 Delete Reference Data

Query Criteria:

System key



Success/Failure

3.4 Establish or Update Accela Receivable

A MiCaRS web service will be developed to establish an accrual based receivable on behalf of Accela.

Input

Accela Invoice #

Customer Information (Name and Mailing Address)

Accela Customer ID

Record #

Invoice Date

Invoice Notes (Text to be included on MiCaRS invoice / delinquency letter) , will be mapped to

reference number in MiCaRS.

List of Line Items

o Amount

o SKU

o Fee Item Description (will be included on MiCARS invoice / delinquency letter)

Output

MiCaRS Invoice # (for reference purposes)

Total Amount (for validation)

Rev 6/2015

3.5 Zero Accela Receivable

A MiCaRS web service will be developed to set the total amount owed to zero on an already established

receivable on behalf of Accela.

Input

Accela Invoice #

Output

MiCaRS Invoice # (for reference purposes)

Total Amount (for validation)

4.0 Assumptions


Project Assumptions

This project will be developed with the Scrum (Agile) methodology, delivering functionality through a series of releases; each release will provide a project milestone.

A project start date within one month of receiving the purchase order.

The project contains dependencies on DTMB for hardware and security approvals that can impact the completion date of the project.

KL&A observes the following non‐working holidays:

emorial Day

y 4th (or the Friday or Monday closest to the 4th)

bor Day

vember 8, (since this is an election year)

anksgiving and the Friday after Thanksgiving

ristmas Eve and Christmas Day

w Year’s Eve and New Year’s Day

All other non‐weekend calendar days, and non‐State holidays, are treated as work days, with the assumption that both KL&A and MDARD stakeholders are available to complete project‐related tasks.

This proposal is a fixed‐price bid. Change requests approved by MDARD or DTMB will affect the price and schedule as defined within the Request of Change (RFC).

KL&A will provide test cases and test plans for User Acceptance Testing (UAT) prior to each release, and will facilitate UAT.

UAT will be concluded within 5 business days of each Sprint release.

UAT test cases will be written and executed using Jama, which provides traceability.

Rev 6/2015

Project Assumptions

Issues found during testing will be recorded in Jira, KL&A’s web‐based issue tracking tool.

Any failures reported during UAT that KL&A deems outside the scope of this project will be handled through a “change request” process, in which KL&A will submit the RFC to DTMB.

Project completion is not dependent upon integration of the web services into Accela Inc., only by acceptance of UAT by business owners.


Role Responsibility

KL&A Project Manager cilitate meetings

epare status reports

aintain project schedule

mmunicate with MDARD and DTMB

anage development team

KL&A Business Analyst date existing MiCaRS documentation

eate new interface documentation

sist in coordination of System, Regression or User Acceptance Testing with the Accela system at any time after development is complete, including after production. Including making appropriate testing environments available.

KL&A Developer velop the application, per provided specifications.

ork with Accela Inc. to ensure data is correct

it testing

DTMB MB will be responsible for evaluating and approving or declining any RFC initiated by KL&A or the MDARD. The project schedule, pricing, and payment schedule will be updated accordingly.

MB will be responsible for deploying the releases to production.

MDARD ree to functional specifications outlined in Statement of Work.

cilitate User Acceptance Testing of the interface if Accela integration is complete during User Acceptance Test Window.

lidate User Acceptance Test Plan and Results.

Rev 6/2015

Role Responsibility

Accela Inc. cela Inc. will be responsible for validating web services against agreed upon functional requirements.

CaRS web services will be consumed by an Accela Inc. server in the SOM’s Zone 2

cela Inc. will be responsible for validating the design and implementation of web services to the Accela Inc. system.

cela Inc will make the appropriate technical resources available via teleconference when requested to ensure system integration. Project management and business analysts are not considered technical resources.

MDOT Accounting Service Center

DOT Accounting Service Center will be responsible for User Acceptance of all changes to the MiCaRS application.

ree to functional specifications outlined in Statement of Work.

6.0 Schedule Project work, defined in “

KL&A will work with the DNR and CAMIS to develop the requirements needed for MiCaRS to consume

data sent from the Central/Campground Reservation System (CRS) and generate required transaction

types in MiCaRS for communication to MAIN. More specifically, the data consumed by MiCaRS will be

used to record deposits, generate refunds and generate journal voucher transactions to move e‐check,

credit card and gift card revenue to the correct coding blocks.

Scope” on page 74, will begin within one month of receiving the purchase order, and will be

completed within 11 weeks. Any RFC’s that impact scope may result in a longer duration.

6.1 Schedule Detail Name Start Finish Work Resource Names

MiCaRS to Accela Interface Mon 8/15/16 Thu 10/27/16 1,131.43 hrs

Initiation Mon 8/15/16 Fri 8/26/16 16 hrs

Project Charter Mon 8/15/16 Fri 8/26/16 16 hrs PM[20%]

Planning Mon 8/15/16 Fri 8/26/16 80 hrs

Requirements & Design Mon 8/15/16 Fri 8/26/16 80 hrs BA

Execution and Control Mon 8/15/16 Thu 10/27/16 1,035.43 hrs

Sprint 1 Mon 8/15/16 Fri 8/26/16 160 hrs Dev 1,Dev 2

Sprint 2 Mon 8/29/16 Fri 9/9/16 191.52 hrs PM[11%],Dev 1,Dev 2,BA[55%]

Sprint 3 Mon 9/12/16 Fri 9/23/16 200 hrs BA[40%],PM[10%],Dev 1,Dev 2

Sprint 4 Mon 9/26/16 Fri 10/7/16 200 hrs BA[40%],PM[10%],Dev 1,Dev 2

System Testing Mon 10/10/16 Fri 10/14/16 128 hrs BA,PM[20%],Dev 1,Dev 2

User Testing Mon 10/17/16 Fri 10/21/16 100 hrs BA,PM[20%],Dev 1,Dev 2[30%]

Training Mon 10/24/16 Wed 10/26/16 24 hrs BA

Rev 6/2015

Name Start Finish Work Resource Names Production Cut‐Over Tue 10/25/16 Thu 10/27/16 31.92 hrs Dev 1,BA[33%]

7.0 Deliverables Table lists the project deliverables.

Deliverables are detailed with further clarification in sections 3.0 through 3.5 of this document.


Deliverables

7 new real‐time interfaces

Database modifications

Updated MiCaRS front end

Update User Manual

Interface Functional Specifications (New Document)

Facilitate User Acceptance Testing

User Training Session

8.0 Cost This is a fixed‐price proposal for $103,800.


Task Hours Cost

Front‐end MiCaRS changes:

Look‐up tables:

SKU to Program Linking

Accela Reference Data

Batch Entry Changes

Display Accela reference data for validation

Automatically link Accela receivables to MiCaRS receivables when available

220 $19,800.00

Rev 6/2015

Task Hours Cost

Real‐time web service interfaces for reference data linking:

List reference data

Add reference data

Delete reference data

160 $14,400.00

Real‐time web services for Check Inquiry

List documents

Get document detail

160 $14,400.00

Real‐time web services for maintain receivables

Create receivable

Zero receivable

Edit receivable

240 $21,600.00

Business Analyst

Update functional design

Update user manual

Facilitate System Testing (MiCaRS and Accela)

Facilitate User Acceptance Testing

Facilitate training

290 $26,100.00

Project Management 60 $7,500.00

Total $103,800.00

Rev 6/2015

9.0 Payment Schedule Upon completion of the project, the MDARD business owners will provide a statement of acceptance in

writing and will remit payment in full.

9.1 Payment Address



P.O. Box 760187



Rev 6/2015




CO

NT

RA

CT

OR


ST

AT

E Pro

gram

M

anag

er

Nordyke, Susan DTMB



John Leigh C

ont

ract

Adm

inis

trat

or Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective July 7, 2016, this Contract is hereby increased by $65,800.00 to migrate Universal Receipts Interface (URI) functionality to MiCARS. See KL&A Proposal V 3.0 dated June 24, 2016, attached. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor


CONTRACT SUMMARY











REVISED EXP. DATE

☐ ☐ Click here to enter a

date. CURRENT VALUE VALUE OF CHANGE NOTICE ESTIMATED AGGREGATE CONTRACT VALUE

$5,036,393.37 $65,800.00 $5,102,193.37

Rev 6/2015

(request/proposal) and agency agreement, and DTMB Procurement approval.


P.O. Box 760187



Phone: (248) 559‐7910

Fax: (248) 559‐8066

kunzleigh.com

Michigan Department of Natural Resources Attn: Dan Sellepack Hollister Bldg. 5th Floor 106 W. Allegan Lansing, MI 48933 Re: Universal Receipts Interface Conversion to MiCaRS

Dear Mr. Sellepack,

Kunz, Leigh and Associates (KL&A) is pleased to propose application development services, which will allow

the Campground Reservation System (CRS) to communicate deposit, refund and revenue data with the

Michigan Department of Natural Resources MiCaRS.

KL&A proposes integrating this project with the MiCaRS for SIGMA project ensuring the delivery of project

activities for the start of SIGMA system test. The proposed project will begin with the receipt of a purchase

order. To accomplish this timeline, KL&A intends to allocate to the project one full‐time Developer, one part‐

time Business Analyst, and one part‐time Project Manager. The total cost for the project will be $65,800.

The attached proposal explains the approach we will take to develop the application, the scope of the project,

project assumptions, roles required for this project and the responsibilities of each role, a list of deliverables,

and the fixed‐price bid for this project, and a payment schedule.

If you have any questions, please contact John Leigh at 517‐202‐4625.

Sincerely,

John Leigh

KL&A Partner

©Error! Unknown document property name. Kunz, Leigh & Associates 71

URI Conversion to MiCaRS

Prepared for:

Michigan Department of Natural Resources525 West Allegan Street

P.O. Box 30473Lansing, MI 48909‐7973

Prepared by:




v3.0

June 24, 2016

Proposal Signatures

Name/Title Signature Date

John K. Leigh, KL&A Partner 06‐24‐2016

KL&A Error! Unknown document property name. 73

Table of Contents

1.0 Project Identification ..................................................................................................................... 74

2.0 Background .................................................................................................................................... 74

3.0 Project Objective ............................................................................................................................ 74

4.0 Scope of Work ................................................................................................................................ 74

4.1 Scope Changes ......................................................................................................................... 75

5.0 Deliverables ................................................................................................................................... 76

6.0 Acceptance Criteria ........................................................................................................................ 76

7.0 Project Control and Reports .......................................................................................................... 76

8.0 Schedule ......................................................................................................................................... 76

8.1 Schedule Assumptions ............................................................................................................ 76

8.2 Schedule .................................................................................................................................. 76

9.0 Cost ................................................................................................................................................ 77

10.0 Payment Schedule ..................................................................................................................... 77

11.0 Roles and Responsibilities ......................................................................................................... 78

12.0 Assumptions .............................................................................................................................. 79


1.0 Project Identification Effective June 2016, the Parties agree that all work to be performed will be pursuant to the Statement of Work and to

the terms of the Kunz, Leigh & Associates (“Contractor”) Contract 071B4300022. Any changes to the scope of Services

described herein shall be pursuant to a modification to this Contract Amendment.

The services described herein (“Services”) and deliverables identified below (“Deliverables”) shall be delivered on a fixed

price basis, which means a predefined project model where the Contractor provides the Services, including any

Deliverables, for a set fee. Payment will be made upon completion of the Milestone for which the State has received all

Services and Deliverables within that Milestone. No partial payment will be accepted.

2.0 Background Kunz, Leigh & Associates (KL&A) has a project with the State of Michigan (SOM) to modify the Michigan Cashiering and

Receivable System (MiCaRS) to communicate with the State’s future ERP system, Advantage (SIGMA). The SOM,

Department of Natural Resources (DNR) is a user of MiCaRS and involved in the MiCaRS for SIGMA project. The DNR is

also in the process of modifying a number of other systems to communicate with the new ERP system. One such system

is the Universal Receipts Interface (URI). A rewrite project is underway to rewrite the URI for SIGMA but also to make

some incremental enhancements.

The URI and MiCaRS have existing interfaces for communicating departmental deposits and refunds. The URI also

communicates journal voucher transactions to the Electronic Journal Voucher (EJV) system, which then communicates

the same transactions to MiCaRS for transmission to MAIN. After some review of MiCaRS, URI, and EJV functionality it

was determined that with the implementation of SIGMA the EJV system is no longer needed and that URI functionality is

in many ways a duplication of functionality offered by MiCaRS. Armed with this information, the decision to roll URI

functionality into MiCaRS as part of the MiCaRS for SIGMA project was confirmed by project stakeholders.

3.0 Project Objective The objective of this Statement of Work (SOW) is to migrate URI functionality to MiCaRS in time for the start of SIGMA

System Test.

KL&A will work with the DNR and CAMIS to develop the requirements needed for MiCaRS to consume data sent from

the Central/Campground Reservation System (CRS) and generate required transaction types in MiCaRS for

communication to MAIN. More specifically, the data consumed by MiCaRS will be used to record deposits, generate

refunds and generate journal voucher transactions to move e‐check, credit card and gift card revenue to the correct

coding blocks.

4.0 Scope of Work As part of the MiCaRS for SIGMA project, KL&A will work with DNR and CAMIS to migrate functionality found in the URI

system to MiCaRS. MiCaRS enhancements include developing a web service to communicate with CRS for POS

transactions, Harbor and Customer refunds as well as e-check/credit card, and gift card transactions.

Changes to MiCaRS will include:

Contents


This change request will make it possible for MiCaRS to communicate with CRS to process both parks POS transactions

as well as Harbor and Customer refunds. The functionality in MiCaRS will require enhancements to make it possible for

MiCaRS to process the incoming data from CRS in order to produce and manage deposits using the cashiering module

and refunds using a refund module.

A MiCaRS web service will be developed to allow consumption by CRS for the submission of transactional data to

MiCARS. The data included in the web service communication includes POS Deposit ticket image file and the POS

transaction file. The POS Deposit ticket Image file includes the deposit ticket number and image of a parks deposit ticket.

The POS transaction file includes detailed information about park deposits as well as Harbor and Customer refund

transactions. Processing of the POS transactions will create a MiCaRS deposit batch or create a MiCaRS refund

dependent on the transaction type.

CRS deposits will flow through the normal cashiering module. A deposit batch will be created for review/modification by

the cashier utilizing already developed MiCaRS data entry module. MiCaRS will be enhanced to display a deposit ticket

image to the cashier to provide a mechanism to validate a deposit transaction.

Harbor refunds will be processed to create a refund when a Harbors account balance nets to a positive value. For those

Harbors with a negative account balance, MiCaRs will log the account balance until a refund is warranted and a refund

will be issued. MiCaRS will be enhanced with a look‐up table to maintain Harbor account information with the

possibility to have the information automatically updated from Sigma.

Both Harbor and Customer refunds will follow the Refund Module flow. Refunds can be reviewed/modified by the

utilizing refund entry/review modules already developed MiCaRS functionality. MiCaRS also provides a refund review

process to allow a manager to accept or reject a refund request.

CRS revenue collected via e‐check, credit card or gift card will generate journal vouchers (Reclasses in MiCaRS

nomenclature) in MiCaRS. CRS provides the required information in the data exchange for MiCaRS to generate a reclass

transaction for submission to SIGMA. KL&A will deploy the reclass transaction that will move the revenue from a generic

coding block to the transactions source coding block as currently implemented with MiCaRS 2.0. This approach to

handling e‐check, credit card and gift card differs from the current process by eliminating a reclassification step. Any

additional reclass steps will be evaluated in terms of Score, Time, and Cost and placed in the Change Request Process if

required.

4.1 Scope Changes Perform requirements gathering sessions with DNR and CAMIS.

Enhance MiCaRS to include a mechanism for users to manage Harbor accounts and bridge to MiCaRS refund

based on Index.

Enhance MiCaRS to manage account balances for Harbor refunds.

Enhance MiCaRS to display the Parks deposit ticket image to the Cashier.

Enhance MiCaRS to include a web service for consumption by CRS to submit revenue, refund and journal

voucher data.

Enhance MiCaRS to process revenue data submitted by CRS for creation of deposit batches.

Enhance MiCaRS to process refund data submitted by CRS for creation of Harbor and Customer refunds.

Enhance MiCaRS to process journal voucher data submitted by CRS for creation of reclassification transactions.

Update all relevant MiCaRS documentation.

Work with DNR and CAMIS to test the MiCaRS modifications.

Contents


5.0 Deliverables This Statement of Work is a Change Request; as such, the deliverables for this Statement of Work will include code and

feature modifications, and updates to existing documentation.


Deliverables

Addition of Functionality to MiCaRS as defined in Section 4.1 Scope Changes

Updated Design Document (will be integrated into MiCaRS design document)

Test Type Approach and Report

System Testing

Support of User Testing

6.0 Acceptance Criteria DNR will provide acceptance of this Change Request by providing written sign‐off of the design document, written sign‐

off of the test type approach and report, and written sign‐off at the completion of the 90‐Day Warranty period.

7.0 Project Control and Reports Project control and reporting will adhere to the MiCaRS for SIGMA project. As part of this Change Request all MiCaRS for

SIGMA project artifacts are to be updated to reflect the work required for completion of this change request.

8.0 Schedule

8.1 Schedule Assumptions

The provided schedule assumes that all MDNR SIGMA Chart of Account decisions are final at the start of

requirements development.

The provided schedule assumes that CAMIS CRS will have finalized design of the data to be exchanged with

MiCaRS.

The provided schedule assumes that consumption of images from CRS will not change.

The provided schedule assumes that system test and user test will be completed as part of the larger MiCaRS for

SIGMA project.

8.2 Schedule Name Start Finish Work Resource Names

URI Conversion to MiCaRS Mon 7/11/16 Thu 10/27/16 682.8 hrs

Initiation Mon 7/11/16 Fri 7/22/16 16 hrs

Contents


Project Charter Mon 7/11/16 Fri 7/22/16 16 hrs PM[20%]

Planning Mon 7/25/16 Fri 8/19/16 120 hrs

Requirements Mon 7/25/16 Fri 8/19/16 120 hrs BA[65%],PM[10%]

Execution and Control Mon 8/8/16 Thu 10/27/16 546.8 hrs

Sprint 1 Mon 8/8/16 Fri 8/19/16 104 hrs Dev,BA[20%],PM[10%]

Sprint 2 Mon 8/22/16 Fri 9/2/16 104 hrs Dev,BA[20%],PM[10%]

Sprint 3 Tue 9/6/16 Mon 9/19/16 104 hrs Dev,BA[20%],PM[10%]

Sprint 4 Tue 9/20/16 Fri 9/30/16 90 hrs Dev,BA[15%],PM[10%]

Sprint 5 Mon 10/3/16 Fri 10/14/16 80 hrs Dev[75%],BA[15%],PM[10%]

Sprint 6 Mon 10/17/16 Thu 10/27/16 64.8 hrs Dev[65%],BA[15%],PM[10%]

9.0 Cost This is a fixed‐price proposal for $65,800.


Task Hours Cost

Requirements Gathering Sessions and Documentation (BA) 120 $12,000

Harbor Refund Supporting Functionality 40 $3,600

Web Service for CRS Data 120 $10,800

Process for Generating Harbor and Customer Refunds 80 $7,200

Process for Generating Deposit Batches 40 $3,600

Process for Generating Reclassifications 100 $9,000

Enhancing Data Entry to Display a Deposit Ticket Image 40 $3,600

Documentation Updates (BA) 60 $6,000

Project Management (PM) 80 $10,000

Total $65,800

10.0 Payment Schedule Upon completion of the project and project acceptance criteria, the DNR business owners will provide a statement of

acceptance in writing and will remit payment in full.

Contents



Role Responsibility

KL&A Project Manager

Carl Meisner

Facilitate meetings

Prepare status reports

Maintain project schedule

Communicate with MDEQ and DTMB

Manage development team

KL&A Business Analyst

Elizabeth Robinson

Update existing MiCaRS documentation

Create new interface documentation

Assist in coordination of System, Regression or User Acceptance Testing with the CRS at any time after development is complete, including after production. Including making appropriate testing environments available.

KL&A Developer

Ben Bockstege

Develop the application, per provided specifications.

Work with CAMIS to ensure data is correct

Unit testing

DTMB DTMB will be responsible for evaluating and approving or declining any RFC initiated by KL&A or the DNR.

DTMB will be responsible for deploying the releases to production.

DNR Agree to functional specifications outlined in Statement of Work.

Facilitate User Acceptance Testing of the interface if CRS integration is complete during User Acceptance Test Window.

Validate User Acceptance Test Plan and Results.

CAMIS Team CAMIS will be part of the requirements gathering process when data exchange is discussed.

CAMIS will make the required modifications to consume the web service provided by MiCaRS. The mentioned modifications are not part of this SOW.

CAMIS will make the appropriate technical resources available via teleconference when requested to ensure system integration. Project management and business analysts are not considered technical resources.

MDOT Accounting Service Center

MDOT Accounting Service Center will be responsible for User Acceptance of all changes to the MiCaRS application.

Agree to functional specifications outlined in Statement of Work.

Contents



Project Assumptions

A project start date will be set upon receipt of a purchase order.

The project contains dependencies on DTMB for hardware and security approvals that can influence the completion date of the project.

KL&A observes the following non‐working holidays:

Memorial Day

July 4th (or the Friday or Monday closest to the 4th)

Labor Day

November 8th, (since this is an election year)

Thanksgiving and the Friday after Thanksgiving

Christmas Eve and Christmas Day

New Year’s Eve and New Year’s Day

All other non‐weekend calendar days, and non‐State holidays, are treated as workdays, with the assumption that both KL&A and MDEQ stakeholders are available to complete project‐related tasks.

This proposal is a fixed‐price bid. Change requests approved by DNR or DTMB will affect the price and schedule as defined within the Request of Change.

KL&A will provide test cases and test plans for User Acceptance Testing (UAT) and will facilitate UAT.

UAT test cases will be written and executed using Jama, which provides traceability.

Issues found during testing will be recorded in JIRA, KL&A’s web‐based issue tracking tool.

Any failures reported during UAT that KL&A deems outside the scope of this project will be handled through a “change request” process.

DTMB will be responsible for deploying releases to production. KL&A will initiate the release process into QA and PROD via an RFC.

KL&A will be responsible for deploying releases to the Dev and Test servers.

CAMIS will be responsible for consuming web services.





CO

NT

RA

CT

OR


ST

AT

E Pro

gram

M

anag

er

Nordyke, Susan DTMB



John Leigh C

ont

ract

Adm

inis

trat

or Terry Mead DTMB

517-202-4625 (517) 284-7035


*******1652

DESCRIPTION: Effective June 17, 2016, this Contract is hereby increased by $2,460.00 to pay for programming costs associated with MiCARS and the interface with SIGMA. This is additional application development work which will allow the users to access the MiCARS 2.0 cashiering system with Active Directory credentials. The code provided by DTMB will be integrated into the MiCARS 2.1 Application. See


CONTRACT SUMMARY











REVISED EXP. DATE

☐ ☐ .


$5,033,933.37 $2,460.00 $5,036,393.37


KL&A Letter of Agreement attached. The total cost of the change notice is $8,800.00. We are using $6,340.00 left on the PO, leaving a balance of $2,460.00. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor (request/proposal) and agency (request) agreement, and DTMB Procurement approval.


Form No. DTMB-3521 (Rev. 10/2015)

AUTHORITY: Act 431 of 1984 COMPLETION: Required PENALTY: Contract change will not be executed unless form is filed

CHANGE NOTICE NO. 3

to

CONTRACT NO. 071B4300022

between

THE STATE OF MICHIGAN

and

NAME & ADDRESS OF CONTRACTOR PRIMARY CONTACT EMAIL

Kunz Leigh & Associates Inc. John Leigh [email protected]

28081 Southfield Road PHONE CONTRACTOR’S TAX ID NO. (LAST FOUR DIGITS ONLY)

Lathrup Village MI, 48076 517‐202‐4625 *******1652

STATE CONTACTS AGENCY NAME PHONE EMAIL

PROGRAM MANAGER / CCI DTMB Susan Nordyke (517)373‐9784 [email protected]

CONTRACT ADMINISTRATOR DTMB Terry Mead (517) 284‐7035 [email protected]

CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services MIRS Rps Ars




January 1, 2014 December 31, 2019 3 ‐ 1 Year December 31, 2019


Net 45 N/A


☐ P-card ☐ Direct Voucher (DV) ☐ Other ☐ Yes ☒No MINIMUM DELIVERY REQUIREMENTS

N/A


EXERCISE OPTION? LENGTH OF OPTION EXERCISE EXTENSION? LENGTH OF EXTENSION

REVISED EXP. DATE

☐ ☐


$4,979,433.37 $54,500.00 $5,033,933.37 DESCRIPTION: Effective May 12, 2016 per attached Statement of Work-Uniform Commercial Code Payment Interface Upgrade to add three different web services and modify the databases for MDOS is hereby incorporated into this contract. This change increases the contract value by $54,500.00. All other terms, conditions, specifications and pricing remain the same. Per (DTMB) contractor


(request/proposal) and agency (request) agreement, and DTMB Procurement approval.




STATEMENT OF WORK

Project Title: UCC Payment Interface Upgrade

Period of Coverage: 2016

Requesting Department: MDOS

Date: 4/5/2016

Agency Project Manager: Dawn Wilson

Phone: 517-322-6280

DTMB Contract Administrator: Todd Elsenheimer

Phone: 517-636-0253


BACKGROUND: Uniform Commercial Code (UCC) has contracted with a new vendor (PCC), which requires new interface connections with various programs, including the payment interface. PROJECT OBJECTIVE:

The approach used for a project is an important part of a project’s success. Of course, a project will have a better

opportunity of success if it has the required funding, skilled resources, executive support, limited impediments, and

limited constraints. However, a project can have all of the right ingredients, but still fail, if the project does not have a

clear project approach.

MDOS has requested services for Kunz, Leigh and Associates to perform development of web services that will allow

RPS/ARS and Uniform Commercial Code to communicate. Currently, these two systems communicate at a database level.

RPS/ARS and UCC require three different web services that will allow UCC to properly function. The three web services

include:

• Control Number validation and amount web service

• Account Number verification web service

• Invoice creation web service

The web services will be located on a server that will be accessible to the new UCC system that is currently being

developed by the vendor PCC. Over the 12‐week schedule, the web services will be developed, tested internally, tested

with the other vendor and then finally tested by the user (User Acceptance Testing) before proceeding to production.

The State of Michigan has addressed the need for a clear project approach by providing projects with a framework, the

State Unified Information Technology Environment (SUITE), which provides documented methodologies for project

management and systems engineering.


“The overall purpose of SUITE is to bring the Department of Technology, Management & Budget

(DTMB) systems development areas up to CMMI Level 3, which ensures consistent process usage

throughout the organization. This includes using the same Project Management Methodology (PMM),

Systems Engineering Methodology (SEM), Process Management, and Supporting Processes across all

systems development areas within DTMB. The overall goal of SUITE is to integrate Project

Management, Systems Engineering, Process Management, and Supporting Processes into a single

unified environment.”

The RPS/ARS and UCC web service project will adhere to SUITE, producing the required documentation with the PMM

and SEM document templates.

The project will integrate the SUITE requirements into the system development life cycle (SDLC) by following the SUITE

PMM/SEM Integration for Agile, with the Scrum Framework as the Agile derivative.

The following illustration depicts a typical Scrum iteration, showing how each Sprint encompasses all SDLC phases,

beginning with requirement analysis through testing to product deployment.


DTMB will provide the necessary hardware for a development environment, a staging/testing environment, and a

production environment. KL&A will work with DTMB to get these environments implemented.

The high‐level requirements for this project have already been identified. These requirements will be entered into the

“product backlog” in Team Foundation Server. The State will have access to this “product backlog” as needed. Functional

and system design will occur at the beginning of the development cycle. Design information will be documented in SEM‐

0501 and SEM‐0604.

The function(s) developed will be deployed to the staging/testing environment, where they will be fully tested with


functional testing, system integration testing (SIT), and user acceptance testing (UAT) that occurs at the end of the Sprint.

The Business Analyst will write test cases for each requirement and bundle the test cases into a test plan for the release.

Each test plan will contain a phase for SIT and a phase for UAT. The Business Analyst will execute and track SIT test

outcomes and will ensure that the KL&A Developers repair any defects. After the SIT phase is complete, the KL&A

Project Manager will facilitate UAT with identified MDOS personnel, who will also track test outcomes. Tracking test

outcomes is as simple as executing the steps identified in the test case and marking each step as passed or failed. The

KL&A Project Manager will ensure that any defects found during UAT are repaired to the satisfaction of MDOS.

When all features defined in the project scope have passed user acceptance testing, KL&A will work with DTMB to deploy

the final release version to the production environment. MDOS will provide written acceptance and remit payment.

SCOPE OF WORK: The proposed solution involves the following:

• Developing the following web services:

• Control Number validation and amount web service

• Account Number verification web service

• Invoice creation web service

• Modifying the current database which includes:

• Adding 2 tables to manage invoice creation (account and non‐account customers)

• Modifying Stored Procedures that exist currently to work with the new web services, table layout and

account customer invoice creation.

• Creating new Stored Procedures to handle new functionality that does not currently exist.

If the above scope negatively affects RPS/ARS remediation changes will be made as part of KL&A maintenance support contract at no cost to MDOS. Negative can be defined as anything that doesn’t work as planned, any error that has a significant and unwanted impact on the function, reliability or output of the system.

Below out‐lines the three web services to be developed in detail:

• Control Number Validation Web Service

Input Parameters

Parameters to be passed to the web service by the UCC System

• Control Number


ARS will validate that Control Number is valid, and obtain the amount of total payments for that control number

if it is valid.

• Output Parameters

Parameters Passed Back by the service from the ARS/RPS System ‐> Amount, Exception

Amount ‐ The Amount will be a currency with two decimals. Amount filed will be zero 0.00 if the exception value

returned is ‘1’, and a specific amount will be present in all cases if exception value returned is ‘0’. The amount

will typically be greater than zero when exception value is ‘0’.

Exception ‐ Exception values of either a ‘0’, or a ‘1’ will be returned by the web service. A ‘0’ will be returned if

the control number exists, and a value of one ‘1’ will be returned if the Control Number does not exist or there is

another problem as determined by ARS/RPS.

Account Number Validation Web Service

Input Parameters

Parameters to be passed to the service by the UCC System ‐> Four digit Numeric Account Number

Output Parameters

Parameters Passed Back by the web service from the RPS/ARS

• Account_Status

• Cust_Name

Account Status is returned to UCC ‐ One of the four values below will be returned:

• Null Status = ‐1

• Good Status = 0

• Cancelled Status = 3

• Delinquent Status = 4

Customer Name is returned to UCC which will be the name of the account holder as stored in RPS/ARS in

Cust_Name field.

Invoicing Web Service

Input Parameters

Parameters to be passed to the service by the UCC System:

Note: The first three Parameters (Total, Transaction Date, and Account Number) are to be required to be passed

for account transactions.

• Total (Total amount due) ‐ Required

• Transaction Date – Date and Time that the work order was created ‐ Required

• Account Number – Optional‐Conditionally required (required if an account transaction)


• Customer Last Name – Optional‐Conditionally required (either An Organization name or the individual to be

passed if there is no account)

• Customer First Name– Optional‐Conditionally required, (required if individual and there is no account)

• Customer Middle Name– Optional

• Customer Organization Name – Optional‐Conditionally required (either Customer Organization name or the

Customer Last Name and First Name to be passed if there is no account)

• Address 1– Optional‐Conditionally required for non‐account holders.

• Address 2–Optional for non‐account holders.

• Address 3–Optional for non‐account holders; UCC System will not be passing this value.

• City–Optional‐Conditionally required for non‐account holders.

• State–Optional‐Conditionally required for non‐account holders.

• Zip–Optional‐Conditionally required for non‐account holders.

• Country–Optional‐Conditionally required for non‐account holders.

• Reference field from UCC – Required, unique identifier that will be the work order number from the UCC system.

Output Parameters

Parameters Passed Back by the service from the RPS/ARS System

1. Invoice Number

2. Error Information: Parameters Required that are missing (passed as a comma separated list of exceptions)

The scope of work necessary to achieve this solution includes:

Working with DTMB to ensure the appropriate infrastructure is implemented.

Creating SUITE PMM and SEM documentation, listed in “Deliverables”

Creating web services stated above

Creating, modifying stored procedures on the RPS/ARS database

Creating, modifying database tables on the RPS/ARS database

Working with DTMB, MDOS, and the PCC vendor of the new UCC system

TASKS: Technical support is required to assist with the following tasks:

• KLA will create EA Solution Assessment and appropriate technical documentation to obtain security


approvals on the application. DTMB will provide the necessary hardware for a development environment, a

staging/testing environment, and a production environment. KL&A will work with DTMB to get these

environments implemented.

• When all features defined in the project scope have passed user acceptance testing, KL&A will provide DTMB an implementation plan that includes all necessary scripts that DTMB can deploy to the final release version to the production environment.


Project Assumptions

• This project will be developed with the Scrum (Agile) methodology, delivering functionality through a series of releases; each release will provide a project milestone.

• The project start date will begin upon of receipt of the purchase order.

• The project contains dependencies on DTMB for hardware that can impact the completion date of the project.

• DTMB will provide a test, and production web server for MiCaRS. DTMB will provide KL&A and MDOS personnel with the necessary credentials to access the servers (excluding production servers and other environments require agency along with DTMB approval for access. MDOS is responsible for the cost of these servers, which is payable to DTMB.

• KL&A observes the following non‐working holidays, Thanksgiving days (November 26 and 27)

• All other non‐weekend calendar days, and non‐State holidays, are treated as work days, with the assumption that both KL&A and MDOS stakeholders are available to complete project‐related tasks.

• This proposal is a fixed‐price bid. Change requests approved by MDOS or DTMB will affect the price and schedule as defined within the request of change (RFC).

• KL&A will provide test cases and test plans for user acceptance testing (UAT) prior to each release and will facilitate UAT.

• UAT will be concluded within 5 business days of each Sprint release.

• UAT test cases will be written and executed using Team Foundation Server.

• Issues found during testing will be recorded in Team Foundation Server

• Any failures reported during UAT that KL&A and MDOS deem outside the scope of this project will be handled through a “change request” process, in which KL&A will submit the request for change (RFC) to DTMB.

• DTMB will be responsible for evaluating and approving or declining any RFC initiated by KL&A or the MDOS, and the project schedule, pricing, and payment schedule will be updated accordingly.

• DTMB will be responsible for executing the scripts identified within the implementation plan for deploying the releases to production. KL&A will initiate the release process via an RFC.

• KL&A will be responsible for deploying releases to the Test server.

• KL&A will use Team Foundation Server for source control.

• KL&A will deliver source code with each release deployment.



Role Responsibility

KL&A ProjectManager • Facilitate meetings

• Maintain project schedule

• Communicate with MDOS and DTMB

• Complete PMM deliverables

• Ensure all SEM deliverables are completed

• Manage development team

KL&A Developer • Develop the application

• Unit testing

• Code reviews

KL&A Business Analyst • Writing SEM document

• Writing/updating the end‐user manual

• Writing test cases and test plans

• Executing System Integration Testing

• Facilitating User Acceptance Testing with MDOS personnel

DELIVERABLES: Deliverables will not be considered complete until the Agency Project Manager has formally accepted them. Deliverables for this project include:

Updated SEM‐0501 Functional Design Document


SEM ‐0602 Test Plan

EA Assessment

SEM‐0502 Use Case documents

SEM‐0402 Requirements

SEM‐0702 Implementation Plan

SEM‐0604 System Design Document

Application Code

New and Enhanced System Functionality (Releases)

Project Charter

Project Management Plan

Project Schedule

Updated DTMB 170

EA Solution Assessment


ACCEPTANCE CRITERIA:

The agencies responsible for providing acceptance of the web services developed for MDOS will indicate acceptance of

the application through a written acceptance and sign‐off of the following project deliverables based on the stage exits

identified within the Systems Engineering Methodology (SEM).

• Requirements

• Design

• User Testing

• Implementation

PROJECT CONTROL AND REPORTS: A weekly progress report must be submitted to the Agency and DTMB Project Managers throughout the life of this project. This report may be submitted with the billing invoice. Each weekly progress report must contain the following:

• Hours: Indicate the number of hours expended during the past two weeks, and the cumulative total to date for the project. Also state whether the remaining hours are sufficient to complete the project.

• Accomplishments: Indicate what was worked on and what was completed during the current reporting period.

• Funds: Indicate the amount of funds expended during the current reporting period, and the cumulative total to date for the project.

• Next Steps: Identify what will be completed in the next two week reporting cycle

• Weekly Status Progress Report

• Identify Issues

LIQUIDATED DAMAGES: The parties acknowledge that late or improper completion of the Work will cause loss and damage to the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result. Therefore, Contractor and the State agree that if there is late or improper completion of the Work and the State does not elect to exercise its rights under Section 2.152 in contract #071B430022, the State is entitled to collect liquidated damages in the amount of $5,000.00 and an additional $100.00 per day for each day Contractor fails to remedy the late or improper completion of the Work. Unauthorized Removal of any Key Personnel It is acknowledged that an Unauthorized Removal will interfere with the timely and proper completion of the Contract, to the loss and damage of the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result of any Unauthorized Removal. Therefore, Contractor and the State agree that in the case of any Unauthorized Removal in respect of which the State does not elect to exercise its rights under Section 2.152, the State may assess liquidated damages against Contractor as specified below. For the Unauthorized Removal of any Key Personnel designated in the Contract or any Statement of Work issued under


it, the liquidated damages amount is $25,000.00 per individual if the Contractor identifies a replacement approved by the State under Section 2.060 in contract #071B430022 assigns the replacement to the Project to shadow the Key Personnel who is leaving for a period of at least 30 days before the Key Personnel’s removal. If Contractor fails to assign a replacement to shadow the removed Key Personnel for at least 30 days, in addition to the $25,000.00 liquidated damages for an Unauthorized Removal, Contractor must pay the amount of $833.33 per day for each day of the 30 day shadow period that the replacement Key Personnel does not shadow the removed Key Personnel, up to $25,000.00 maximum per individual. The total liquidated damages that may be assessed per Unauthorized Removal and failure to provide 30 days of shadowing must not exceed $50,000.00 per individual. SPECIFIC DEPARTMENT STANDARDS: Agency standards, in addition to DTMB standards PAYMENT SCHEDULE:

Project work will begin upon receiving the purchase order and will be completed within twelve weeks. Any RFCs that

impact scope may result in a longer duration.

Payment will be made on a satisfactory final acceptance at conclusion of the contract basis. DTMB will pay CONTRACTOR upon receipt of properly completed invoices which shall be submitted to the billing address on the State issued purchase order not more often than monthly. DTMB Contracts area will coordinate obtaining Agency Project Manager and DTMB Project Manager approvals. All invoices should reflect actual work completed by payment date, and must be approved by the Agency Project Manager and DTMB Project Manager prior to payment. The invoices shall describe and document to the State’s satisfaction a description of the work performed, the progress of the project, and fees. When expenses are invoiced, receipts will need to be provided along with a detailed breakdown of each type of expense. Payment shall be considered timely if made by the DTMB within forty‐five (45) days after receipt of properly completed invoices.



P.O. Box 760187



COST/RATE:

This is a fixed‐price proposal for $54,500.

Table: Cost Breakdown

Task Hours Cost

Web Service Development 140 $14,700.00

Database Development 100 $10,500.00


BA Test Support 100 $10,500.00

BA (Documentation) 60 $6,300.00

Project Management 100 $12,500.00

Total 500 $54,500.00 EXPENSES: The State will not pay for any travel expenses, including hotel, mileage, meals, parking, etc. PROJECT CONTACTS: The designated Agency Project Manager is: Dawn Wilson Michigan Department of State Office of Customer Services/Direct Services Section Secondary Complex, SOS Building, 1st floor north 7064 Crowner Drive Lansing, MI 48918 517‐322‐6280 517‐322‐3434 [email protected] The designated DTMB Project Manager is: Todd Elsenheimer DTMB Enterprise Portfolio Management Office 7285 Parson Drive Dimondale, MI 636‐0253 Email: [email protected] The DTMB Contract Administrator for this project is: David Hatch Michigan Department of Technology, Management and Budget DTMB Purchasing Operations ‐ Stevens T. Mason Building – 2nd Floor 530 W. Allegan Street Lansing, MI 48933 517‐284‐7044 Email: [email protected] AGENCY RESPONSIBILITIES: Meet with vendor to describe needs and requirements of the project and review progress, will verify user acceptance testing, acceptance of completed tasks/deliverables.


LOCATION OF WHERE THE WORK IS TO BE PERFORMED: Consultants will work at Secondary Complex, SOS Building, 7064 Crowner Drive, Lansing, Michigan. EXPECTED CONTRACTOR WORK HOURS AND CONDITIONS: Work hours are not to exceed eight (8) hours a day, forty (40) hours a week. Normal working hours of 8:00 am to 5:00 pm are to be observed unless otherwise agreed to in writing. No overtime will be permitted.


Form No. DTMB-3521 (Rev. 5/2015) AUTHORITY: Act 431 of 1984 COMPLETION: Required PENALTY: Contract change will not be executed unless form is filed

STATE OF MICHIGAN

DEPARTMENT OF TECHNOLOGY, MANAGEMENT AND BUDGET PROCUREMENT

P.O. BOX 30026, LANSING, MI 48909 OR

525 W. ALLEGAN, LANSING, MI 48933

CHANGE NOTICE NO. 2 (REVISED)

to


between


and


Kunz, Leigh & Associates John Leigh [email protected]


Lathrup Village, MI 48076 (517) 202‐4625 1652


PROGRAM MANAGER / CCI DTMB Susan Nordyke (517) 373‐9784 [email protected]

CONTRACT ADMINISTRATOR DTMB David Hatch (517) 284‐7044 [email protected]

CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services for MIRS, RPS/ARS, and MiCARS

INITIAL EFFECTIVE DATE

INITIAL EXPIRATION DATE



January 1, 2014 December 31, 2019 (3) 1 Year Options December 31, 2019


Net 45 N/A



N/A



REVISED EXP. DATE



$3,152,233.37 $1,827,200.00 $4,979,433.37 DESCRIPTION: Effective September 11, 2015, this Contract is hereby increased by $884,000.00 per the attached Statement of Work. These funds are required for Fiscal Year 2015. The remaining required funds ($943,200.00) to fulfill the requirements of this Statement of Work will be added per an additional Change Notice upon State Administrative Board approval. All other terms, conditions, specifications, and pricing remain the same, per Contractor and Agency agreement, DTMB Procurement approval and State Administrative Board approval on


August 18, 2015. Available Ad Board dollars remaining after this request for SIGMA Interface work for this Contract: $70,000.00 Effective September 30, 2015, the revised Contract increase is $1,827,200.00 per the attached Statement of Work. All other terms, conditions, specifications, and pricing, remain the same per Contractor and Agency agreement, DTMB Procurement approval and State Administrative Board approval on September 30, 2015.


Kunz, Leigh & Associates MIRS, RPS/ARS, and MiCARS SIGMA Interface Statement of Work

VI. Background The SIGMA system will impact all areas of State business operations, from payroll and purchasing, to payment of suppliers, disbursement of grant funding and processing of unemployment, financial aid and child support. The system must interface with each of the applications managing these process areas, as well as those utilized for payment processing and revenue generating applications. To successfully implement the required functionality and realize projected efficiencies of SIGMA, the interfaces must be in established, tested and fully implemented. The State does not have resources with the necessary technical ability and bandwidth to accomplish the transition independently. Thus contract change notices will be processed for those interfaces which can be managed through existing contracts and staff augmentation resources will be obtained through bids completed under the pre-qualification program.

VII. Environment / IT Standards

Confirm with Sigma Team

Agency Test Type Environment

MDHHS Unit Test Integration Test System & Standards Test

Test SSO Development Web Development Database

MDHHS Performance Test User Acceptance Test Regression Test

QA SSO Staging Web Staging Database

MDOT (MDARD, MDNR, MDEQ, MDOT) Unit Test Integration Test System & Standards Test

Test MiLogin Development Web Development Database

MDOT (MDARD, MDNR, MDEQ, MDOT) Performance Test User Acceptance Test Regression Test

QA MiLogin Staging Web Staging Database

MSP Unit Test Integration Test System & Standards Test

Test MiCiJIN Development Web Development Database

MSP Performance Test User Acceptance Test Regression Test

QA MiCiJIN Staging Web Staging Database

MDOS Unit Test Integration Test System & Standards Test

Test Workstation Development Database



MDOS Performance Test User Acceptance Test Regression Test

Test Workstation Staging Database

VIII. Project Objective Successfully design and implement necessary interfaces between existing systems and SIGMA for continued and improved operations and business processes throughout the state. The next generation of MiCaRS-RPS is now required. The State of Michigan is implementing a replacement for MAIN, a CGI product named Advantage. Project SIGMA, as it were named, is the State of Michigan effort to implement Advantage. MiCaRS-RPS will be impacted by the change from MAIN to Advantage and will require changes to keep all of the agencies doing business. The objective of this project is to make MiCaRS-RPS ready to interface with Advantage. The objective can be broken down to the following activities:

1) To ease the transition from MAIN to Advantage standardize the MDOT Service Center software. This will be achieved by migrating MDARD and MDNR from RPS to MiCaRS and converting MDEQ and MDOT from Navision to MiCaRS. This project activity will be referred to as MiCaRS 2.0 for the remainder of the document.

2) Perform an impact analysis to understand how MiCaRS-RPS will be impacted by Advantage. 3) Upgrade MiCaRS to interface with Advantage. This project activity will be referred to as MiCaRS 3.0 for the remainder of the document. 4) Upgrade RPS at MDOS to interface with Advantage. This project activity will be referred to as RPS for SIGMA for the remainder of the document.

IX. Scope of Work

b. Deliverables


c. Acceptance Criteria – List in Requirements column for Milestone Acceptance & Signoff row, and identify those authorized to signoff in Acceptance/Signoff Column.

d. Cost/Price Model – List in table, Hours, Rate, Total and Total Payment Columns. e. Project Contacts – Should all be listed on iTRAC, either in contact fields, description fields or on an attached document. f. Agency Responsibilities and Assumptions – Identify in State Staff and Roles columns. g. Contractor Staff – Numbers, roles, anticipated hours, and duration by task and total columns below.

Kunz, Leigh & Associates (KL&A); Contract Number: 071B4300022


X. Terms and Conditions

Per established contract #071B4300022 Project Plan:



Date

State Staff

State Staff

Hours

Contractor Staff Role Hours Rate Total Acceptance / Signoff

Total Payment

Milestone I Impact Analysis

and Requirements

Project Charter Project Management Plan Impact Analysis Document Requirements Document

10/09/2015 Business Analyst

Project Manager

Meet with agency SME’s to establish interface requirements

800 $105 $84,000 Signatures provided by Project Sponsors

$84,000

Milestone II MDARD & MDNR

MiCaRS 2.0

Project Charter Project Management Plan Enterprise Architecture Solution Assessment Project Schedule Project Control Reporting Data Migration Plan Application Code Test Plan Test Cases Test Type Approach

12/07/2015 System Architect

Business Analyst

Project Manager

Developer

Work with MDOT Service Center team to migrate from RPS to MiCaRS 2.0

380 $105 $40,000 Delivery of all system features Successful completion of UAT Successful implementation of the system Signatures provided by Project Sponsors on documents

$40,000




Date

State Staff

State Staff

Hours


Total Payment

Training Plan

Training

Installation Plan System Cut-over

Milestone III MDEQ & MDOT

MiCaRS 2.0

Project Charter Project Management Plan Enterprise Architecture Solution Assessment Project Schedule Project Control Reporting Data Migration Plan Application Code Test Plan Test Cases Test Type Approach Training Plan Training Installation Plan System Cut-over


Business Analyst

Project Manager

Developer

Work with MDOT Service Center team to migrate from Navison to MiCaRS 2.0


$75,600




Date

State Staff

State Staff

Hours


Total Payment

Milestone IV MiCaRS (3.0) for SIGMA Design (MDHHS, MDOT, MSP)

Enterprise Architecture Solution Assessment Project Schedule Project Control Reporting Functional Design Document System Design Document


Business Analyst

Project Manager

Developer

Work to review and approve the technical environment, produce design documents and report project status


$128,100

Milestone V RPS for SIGMA Design (MDOS)



Business Analyst

Project Manager

Developer



$50,400

Milestone VI MiCaRS (3.0) for SIGMA Testing (MDHHS, MDOT, MSP)

Application Code Requirements Traceability Matrix Test Plan Test Cases Test Type Approach and


Project Manager

Developer

Work to make the necessary application changes and test the changes

2440 $105 $256,200 Delivery of all system features, entry of final UAT Signatures provided by Project Sponsors on documents

$256,200




Date

State Staff

State Staff

Hours


Total Payment

Report Data Migration Plan Training Plan

Milestone VII RPS for SIGMA Testing (MDOS)

Application Code Requirements Traceability Matrix Test Plan Test Cases Test Type Approach and Report Data Migration Plan Training Plan


Project Manager

Developer



$100,800

Milestone VIII MiCaRS (3.0) for SIGMA Implementation (MDHHS, MDOT, MSP)

Maintenance Plan Software Configuration Management Plan Installation Plan Training System Cut-over


Project Manager

Developer

Work to implement the system in a State of Michigan environment

1220

$105 $128,100 Successful implementation of the system Signatures provided by Project Sponsors on documents

$128,100

Milestone IX RPS for SIGMA Implementation (MDOS)

Maintenance Plan Software Configuration Management Plan Installation Plan Training


Project Manager

Developer


480 $105 $50,400 Successful implementation of the system Signatures provided by Project Sponsors on documents

$50,400




Date

State Staff

State Staff

Hours


Total Payment

System Cut-over

Milestone X Final Acceptance

Project Closeout Document Completion of 90 day Warranty Period


Project Manager

Developer

Closeout project and support the application after cut-over

Holdback

$182,720 Completion of Warranty Period without Blocker, Critical or Major (without Workaround) defects

$182,720

Monthly Bill MDHHS

Flat bill May 2015 to October 2016 ($8,400 per month)

Business Analyst

Project Manager

Developer


1440 $105 $151,200 $151,200

Monthly Bill MDOS

Flat bill May 2015 to October 2016 ($10,266.66 per month)

Business Analyst

Project Manager

Developer


1760 $105 $184,800 $184,800

Monthly Bill MDOT


Business Analyst

Project Manager

Developer


2320 $105 $243,680 $243,680

Monthly Bill MSP


Business Analyst

Project Manager

Developer


1440 $105 $151,200 $151,200

Totals

6 $1,827,200


$1,827,200


Change Notice Number: 2 (REVISED)

Contract Number: 071B4300022

FOR THE CONTRACTOR: Kunz, Leigh & Associates Company Name

Authorized Agent Signature

John Leigh Authorized Agent (Print or Type)

Date

FOR THE STATE: Signature

Sharon Walenga-Maynard, Sourcing Director Name & Title

DTMB Procurement Agency

Date

Rev 6/2015

Rev 6/2015

Form No. DTMB-3521 (Rev. 5/2015) AUTHORITY: Act 431 of 1984 COMPLETION: Required PENALTY: Contract change will not be executed unless form is filed

STATE OF MICHIGAN




CHANGE NOTICE NO. 2

to


between


and




Lathrup Village, MI 48076 (517) 202‐4625 1652


PROGRAM MANAGER / CCI DTMB Susan Nordyke (517) 373‐9784 [email protected]

CONTRACT ADMINISTRATOR DTMB David Hatch (517) 284‐7044 [email protected]

CONTRACT SUMMARY

DESCRIPTION: Enterprise Support Services for MIRS, RPS/ARS, and MiCARS

INITIAL EFFECTIVE DATE

INITIAL EXPIRATION DATE



January 1, 2014 December 31, 2019 (3) 1 Year Options December 31, 2019


Net 45 N/A



N/A



REVISED EXP. DATE



$3,152,233.37 $884,000.00 $4,036,233.37 DESCRIPTION: Effective September 11, 2015, this Contract is hereby increased by $884,000.00 per the attached Statement of Work. These funds are required for Fiscal Year 2015. The remaining required funds ($943,200.00) to fulfill the requirements of this Statement of Work will be added per an additional Change Notice upon State

Rev 6/2015

Administrative Board approval. All other terms, conditions, specifications, and pricing remain the same, per Contractor and Agency agreement, DTMB Procurement approval and State Administrative Board approval on August 18, 2015. Available Ad Board dollars remaining after this request for SIGMA Interface work for this Contract: $70,000.00


Kunz, Leigh & Associates MIRS, RPS/ARS, and MiCARS SIGMA Interface Statement of Work

XI. Background The SIGMA system will impact all areas of State business operations, from payroll and purchasing, to payment of suppliers, disbursement of grant funding and processing of unemployment, financial aid and child support. The system must interface with each of the applications managing these process areas, as well as those utilized for payment processing and revenue generating applications. To successfully implement the required functionality and realize projected efficiencies of SIGMA, the interfaces must be in established, tested and fully implemented. The State does not have resources with the necessary technical ability and bandwidth to accomplish the transition independently. Thus contract change notices will be processed for those interfaces which can be managed through existing contracts and staff augmentation resources will be obtained through bids completed under the pre-qualification program.

XII. Environment / IT Standards

Confirm with Sigma Team


MDHHS Unit Test Integration Test System & Standards Test

Test SSO Development Web Development Database

MDHHS Performance Test User Acceptance Test Regression Test

QA SSO Staging Web Staging Database

MDOT (MDARD, MDNR, MDEQ, MDOT) Unit Test Integration Test System & Standards Test

Test MiLogin Development Web Development Database

MDOT (MDARD, MDNR, MDEQ, MDOT) Performance Test User Acceptance Test Regression Test

QA MiLogin Staging Web Staging Database

MSP Unit Test Integration Test System & Standards Test

Test MiCiJIN Development Web Development Database

MSP Performance Test User Acceptance Test Regression Test

QA MiCiJIN Staging Web Staging Database

MDOS Unit Test Test Workstation

Rev 6/2015


Integration Test System & Standards Test

Development Database

MDOS Performance Test User Acceptance Test Regression Test

Test Workstation Staging Database

XIII. Project Objective Successfully design and implement necessary interfaces between existing systems and SIGMA for continued and improved operations and business processes throughout the state. The next generation of MiCaRS-RPS is now required. The State of Michigan is implementing a replacement for MAIN, a CGI product named Advantage. Project SIGMA, as it were named, is the State of Michigan effort to implement Advantage. MiCaRS-RPS will be impacted by the change from MAIN to Advantage and will require changes to keep all of the agencies doing business. The objective of this project is to make MiCaRS-RPS ready to interface with Advantage. The objective can be broken down to the following activities:

5) To ease the transition from MAIN to Advantage standardize the MDOT Service Center software. This will be achieved by migrating MDARD and MDNR from RPS to MiCaRS and converting MDEQ and MDOT from Navision to MiCaRS. This project activity will be referred to as MiCaRS 2.0 for the remainder of the document.

6) Perform an impact analysis to understand how MiCaRS-RPS will be impacted by Advantage. 7) Upgrade MiCaRS to interface with Advantage. This project activity will be referred to as MiCaRS 3.0 for the remainder of the document. 8) Upgrade RPS at MDOS to interface with Advantage. This project activity will be referred to as RPS for SIGMA for the remainder of the document.

XIV. Scope of Work

h. Deliverables


i. Acceptance Criteria – List in Requirements column for Milestone Acceptance & Signoff row, and identify those authorized to signoff in Acceptance/Signoff Column.

j. Cost/Price Model – List in table, Hours, Rate, Total and Total Payment Columns. k. Project Contacts – Should all be listed on iTRAC, either in contact fields, description fields or on an attached document. l. Agency Responsibilities and Assumptions – Identify in State Staff and Roles columns.

Kunz, Leigh & Associates (KL&A); Contract Number: 071B4300022

Rev 6/2015

m. Contractor Staff – Numbers, roles, anticipated hours, and duration by task and total columns below.

XV. Terms and Conditions

Per established contract #071B4300022

Project Plan:



Date

State Staff

State Staff

Hours


Total Payment

Milestone I Impact Analysis

and Requirements

Project Charter Project Management Plan Impact Analysis Document Requirements Document


Project Manager

Meet with agency SME’s to establish interface requirements


$84,000

Milestone II MDARD & MDNR

MiCaRS 2.0

Project Charter Project Management Plan Enterprise Architecture Solution Assessment Project Schedule Project Control Reporting Data Migration Plan Application Code Test Plan


Business Analyst

Project Manager

Developer

Work with MDOT Service Center team to migrate from RPS to MiCaRS 2.0


$40,000

Rev 6/2015



Date

State Staff

State Staff

Hours


Total Payment

Test Cases Test Type Approach Training Plan Training Installation Plan System Cut-over

Milestone III

MDEQ & MDOT MiCaRS 2.0

Project Charter Project Management Plan Enterprise Architecture Solution Assessment Project Schedule Project Control Reporting Data Migration Plan Application Code Test Plan Test Cases Test Type Approach Training Plan


Business Analyst

Project Manager

Developer

Work with MDOT Service Center team to migrate from Navison to MiCaRS 2.0


$75,600

Rev 6/2015



Date

State Staff

State Staff

Hours


Total Payment

Training Installation Plan System Cut-over

Milestone IV MiCaRS (3.0) for SIGMA Design (MDHHS, MDOT, MSP)



Business Analyst

Project Manager

Developer



$128,100

Milestone V RPS for SIGMA Design (MDOS)



Business Analyst

Project Manager

Developer



$50,400

Milestone VI MiCaRS (3.0) for SIGMA Testing (MDHHS, MDOT, MSP)

Application Code Requirements Traceability Matrix


Project Manager

Developer

Work to make the necessary application changes and test the

2440 $105 $256,200 Delivery of all system features, entry of final UAT Signatures provided by

$256,200

Rev 6/2015



Date

State Staff

State Staff

Hours


Total Payment

Test Plan Test Cases Test Type Approach and Report Data Migration Plan Training Plan

changes Project Sponsors on documents

Milestone VII RPS for SIGMA Testing (MDOS)

Application Code Requirements Traceability Matrix Test Plan Test Cases Test Type Approach and Report Data Migration Plan Training Plan


Project Manager

Developer



$100,800

Milestone VIII MiCaRS (3.0) for SIGMA Implementation (MDHHS, MDOT, MSP)



Project Manager

Developer


1220

$105 $128,100 Successful implementation of the system Signatures provided by Project Sponsors on documents

$128,100

Rev 6/2015



Date

State Staff

State Staff

Hours


Total Payment

Milestone IX RPS for SIGMA Implementation (MDOS)



Project Manager

Developer


480 $105 $50,400 Successful implementation of the system Signatures provided by Project Sponsors on documents

$50,400

Milestone X Final Acceptance

Project Closeout Document Completion of 90 day Warranty Period


Project Manager

Developer

Closeout project and support the application after cut-over

Holdback

$182,720 Completion of Warranty Period without Blocker, Critical or Major (without Workaround) defects

$182,720

Monthly Bill MDHHS


Business Analyst

Project Manager

Developer


1440 $105 $151,200 $151,200

Monthly Bill MDOS


Business Analyst

Project Manager

Developer


1760 $105 $184,800 $184,800

Monthly Bill MDOT


Business Analyst

Project Manager

Developer


2320 $105 $243,680 $243,680

Monthly Bill Flat bill May 2015 Business Analyst Work 1440 $105 $151,200 $151,200

Rev 6/2015



Date

State Staff

State Staff

Hours


Total Payment

MSP to October 2016 ($8,400 per month)

Project Manager

Developer

completed by contract resources through the life of the project

Totals

6 $1,827,200


$1,827,200


Form No. DTMB-3522 (Rev. 4/2012) AUTHORITY: Act 431 of 1984 COMPLETION: Required PENALTY: Contract will not be executed unless form is filed

STATE OF MICHIGAN




NOTICE OF


between


and

NAME & ADDRESS OF CONTRACTOR: PRIMARY CONTACT EMAIL


28081 Southfield Road TELEPHONE CONTRACTOR #, MAIL CODE

Lathrup Village, MI 48076 (517) 202‐4625


CONTRACT COMPLIANCE INSPECTOR: DTMB David Borzenski 517‐241‐4652 [email protected]

BUYER: DTMB Whitnie Zuker 517‐335‐5306 [email protected]

CONTRACT SUMMARY:

DESCRIPTION:

Enterprise Support Services for MIRS, RPS/ARS, and MiCARS

INITIAL TERM EFFECTIVE DATE INITIAL EXPIRATION DATE AVAILABLE OPTIONS

5 years January 1, 2014 December 31, 2019 See Section 2.002

PAYMENT TERMS F.O.B SHIPPED SHIPPED FROM

Net 45 N/A N/A N/A

ALTERNATE PAYMENT OPTIONS: AVAILABLE TO MiDEAL PARTICIPANTS

P-card Direct Voucher (DV) Other YES NO

MINIMUM DELIVERY REQUIREMENTS:

N/A

MISCELLANEOUS INFORMATION:

N/A

ESTIMATED CONTRACT VALUE AT TIME OF EXECUTION: $3,152,233.37

Rev 6/2015

Form No. DTMB-3522 (Rev. 4/2012) AUTHORITY: Act 431 of 1984 COMPLETION: Required PENALTY: Contract will not be executed unless form is filed

STATE OF MICHIGAN





between


and

NAME & ADDRESS OF CONTRACTOR: PRIMARY CONTACT EMAIL


28081 Southfield Road TELEPHONE CONTRACTOR #, MAIL CODE

Lathrup Village, MI 48076 (517) 202‐4625


CONTRACT COMPLIANCE INSPECTOR: DTMB David Borzenski 517‐241‐4652 [email protected]

BUYER: DTMB Whitnie Zuker 517‐335‐5306 [email protected]

CONTRACT SUMMARY:

DESCRIPTION:

Enterprise Support Services for MIRS, RPS/ARS, and MiCARS INITIAL TERM EFFECTIVE DATE INITIAL EXPIRATION DATE AVAILABLE OPTIONS

5 years January 1, 2014 December 31, 2019 See Section 2.002

PAYMENT TERMS F.O.B SHIPPED SHIPPED FROM

Net 45 N/A N/A N/A

ALTERNATE PAYMENT OPTIONS: AVAILABLE TO MiDEAL PARTICIPANTS

P-card Direct Voucher (DV) Other YES NO

MINIMUM DELIVERY REQUIREMENTS:

N/A

MISCELLANEOUS INFORMATION:

N/A

ESTIMATED CONTRACT VALUE AT TIME OF EXECUTION: $3,152,233.37 THIS IS NOT AN ORDER: This Contract Agreement is awarded on the basis of our inquiry bearing the solicitation #0071141114B0000577. Orders for delivery will be issued directly by the Department of Technology, Management & Budget through the issuance of a Purchase Order Form.

Rev 6/2015

Form No. DTMB-3522 (Rev. 4/2012)

Notice of Contract #: 071B4300022

FOR THE CONTRACTOR: FOR THE STATE: Kunz, Leigh & Associates

Firm Name Signature Jeff Brownlee, Chief Procurement Officer

Authorized Agent Signature Name/Title

DTMB Procurement Authorized Agent (Print or Type) Enter Name of Agency

Date Date

CONTRACT #071B4300022

121

Table of Contents

Article 1 – Statement of Work (SOW) 125

Bid41.000 Project Identification 125 1.001 Project Request 125 1.002 Background 125

1.100 Scope of Work and Deliverables 125 1.101 In Scope 125 1.102 Out Of Scope 126 1.103 Environment 126

1.200 Roles and Responsibilities 135 1.201 Contractor Staff, Roles, And Responsibilities 135 1.202 State Staff, Roles, And Responsibilities 136

1.300 Project Plan 137 1.301 Project Plan Management 137

1.600 Compensation and Payment 140 1.601 Compensation And Payment 140

Article 2, Terms and Conditions 143

2.000 Contract Structure and Term 143 2.001 Contract Term 143 2.002 Options to Renew 143 2.003 Legal Effect 143 2.004 Attachments & Exhibits 143 2.005 Ordering 143 2.006 Order of Precedence 143 2.007 Headings 144 2.008 Form, Function & Utility 144 2.009 Reformation and Severability 144

2.010 Consents and Approvals 144 2.011 No Waiver of Default 144 2.012 Survival 144

2.020 Contract Administration 144 2.021 Issuing Office 144 2.022 Contract Compliance Inspector 144 2.023 Project Manager – See Section 1.201 145 2.024 Change Requests 145 2.025 Notices 146 2.026 Binding Commitments 146 2.027 Relationship of the Parties 146 2.028 Covenant of Good Faith 147 2.029 Assignments 147

2.030 General Provisions 147 2.031 Administrative Fee and Reporting 147 2.032 Media Releases 148 2.033 Contract Distribution 148 2.034 Permits 148 2.035 Website Incorporation 148 2.036 Future Bidding Preclusion 148 2.037 Freedom of Information 148 2.038 Disaster Recovery 148

2.040 Financial Provisions 148 2.041 Fixed Prices for Services/Deliverables 148 2.042 Adjustments for Reductions in Scope of Services/Deliverables 149 2.043 Services/Deliverables Covered 149 2.044 Invoicing and Payment – In General 149 2.045 Pro-ration 149 2.046 Antitrust Assignment 149 2.047 Final Payment 149 2.048 Electronic Payment Requirement 150


122

2.050 Taxes 150 2.051 Employment Taxes 150 2.052 Sales and Use Taxes 150

2.060 Contract Management 150 2.061 Contractor Personnel Qualifications 150 2.062 Contractor Key Personnel 150 2.063 Re-assignment of Personnel at the State’s Request 151 2.064 Contractor Personnel Location 151 2.065 Contractor Identification 151 2.066 Cooperation with Third Parties 151 2.067 Contract Management Responsibilities 151 2.068 Contractor Return of State Equipment/Resources 152

2.070 Subcontracting by Contractor 152 2.071 Contractor full Responsibility 152 2.072 State Consent to delegation 152 2.073 SubContractor bound to Contract 152 2.074 Flow Down 153 2.075 Competitive Selection 153

2.080 State Responsibilities 153 2.081 Equipment 153 2.082 Facilities 153

2.090 Security 153 2.091 Background Checks 153

2.100 Confidentiality 153 2.101 Confidentiality 153 2.102 Protection and Destruction of Confidential Information 154 2.103 PCI DATA Security Standard 154 2.104 Exclusions 154 2.105 No Implied Rights 155 2.106 Security Breach Notification 155 2.107 Respective Obligations 155

2.110 Records and Inspections 155 2.111 Inspection of Work Performed 155 2.112 Retention of Records 155 2.113 Examination of Records 155 2.114 Audit Resolution 156 2.115 Errors 156

2.120 Warranties 156 2.121 Warranties and Representations 156 2.122 reserved 157 2.123 ReserveD 157 2.124 Reserved 157 2.125 reserved 157 2.126 reserved 157 2.127 reserved 157 2.128 Consequences for Breach 157

2.130 Insurance 157 2.13.1 Liability Insurance 157 2.13.2 SubContractor Insurance Coverage 159 2.13.3 Certificates of Insurance 159

2.140 Indemnification 160 2.141 General Indemnification 160 2.142 Code Indemnification 160 2.143 Employee Indemnification 160 2.144 Patent/Copyright Infringement Indemnification 160 2.145 Continuation of Indemnification Obligations 161 2.146 Indemnification Procedures 161

2.150 Termination/Cancellation 161 2.151 Notice and Right to Cure 161 2.152 Termination for Cause 162


123

2.153 Termination for Convenience 162 2.154 Termination for Non-Appropriation 162 2.155 Termination for Criminal Conviction 163 2.156 Termination for Approvals Rescinded 163 2.157 Rights and Obligations upon Termination 163 2.158 Reservation of Rights 163

2.160 Termination by Contractor 164 2.161 Termination by Contractor 164

2.170 Transition Responsibilities 164 2.171 Contractor Transition Responsibilities 164 2.172 Contractor Personnel Transition 164 2.173 Contractor Information Transition 164 2.174 Contractor Software Transition 164 2.175 Transition Payments 165 2.176 State Transition Responsibilities 165

2.180 Stop Work 165 2.181 Stop Work Orders 165 2.182 Cancellation or Expiration of Stop Work Order 165 2.183 Allowance of Contractor Costs 165

2.190 Dispute Resolution 165 2.191 In General 165 2.192 Informal Dispute Resolution 166 2.193 Injunctive Relief 166 2.194 Continued Performance 166

2.200 Federal and State Contract Requirements 166 2.201 Nondiscrimination 166 2.202 Unfair Labor Practices 167 2.203 Workplace Safety and Discriminatory Harassment 167 2.204 reserved 167

2.210 Governing Law 167 2.211 Governing Law 167 2.212 Compliance with Laws 167 2.213 Jurisdiction 167

2.220 Limitation of Liability 167 2.221 Limitation of Liability 167

2.230 Disclosure Responsibilities 167 2.231 Disclosure of Litigation 168 2.232 Call Center Disclosure 168 2.233 Bankruptcy 168

2.240 Performance 169 2.241 Time of Performance 169 2.242 Service Level Agreement (SLA) 169 2.243 Liquidated Damages 170 2.244 Excusable Failure 170

2.250 Approval of Deliverables 171 2.251 Delivery of Deliverables 171 2.252 Contractor System Testing 171 2.253 Approval of Deliverables, In General 172 2.254 Process for Approval of Written Deliverables 173 2.255 Process for Approval of Custom Software Deliverables 173 2.256 Final Acceptance 174

2.260 Ownership 174 2.261 Ownership of Work Product by State 174 2.262 Vesting of Rights 174 2.263 Rights in Data 174 2.264 Ownership of Materials 175

2.270 State Standards 175 2.271 Existing Technology Standards 175


124

2.272 Acceptable Use Policy 175 2.273 Systems Changes 175 2.274 Electronic Receipt Processing Standard 175

2.280 Extended Purchasing Program 175 2.281 Extended Purchasing Program 175

2.290 Environmental Provision 175 2.291 reserved 175

2.300 Deliverables 175 2.301 reserved 175 2.302 reserved 175

2.310 Software Warranties 175 2.311 Performance Warranty 175 2.312 No Surreptitious Code Warranty 176 2.313 Calendar Warranty 176 2.314 Third-party Software Warranty 176 2.315 reserved 176

2.320 Software Licensing 176 2.321 reserved. 176 2.322 reserved 177 2.323 reserved 177 2.324 reserved 177 2.325 Pre-existing Materials for Custom Software Deliverables 177

2.330 Source Code Escrow 177 2.331 Definition 177 2.332 Delivery of Source Code into Escrow 177 2.333 Delivery of New Source Code into Escrow 177 2.334 Verification 177 2.335 Escrow Fees 177 2.336 Release Events 177 2.337 Release Event Procedures 178 2.338 License 178 2.339 Derivative Works 178

Glossary 179

Attachment 1 -Support Level Agreement 181

Attachment 2 - Organizational Chart/Responsibility Matrix 182

Appendix A - COST TABLES 184


125

Article 1 – Statement of Work (SOW)

Bid41.000 Project Identification

1.001 PROJECT REQUEST

The State of Michigan (SOM) Department of Technology, Management and Budget (DTMB) has issued this Contract to provide maintenance support and enhancement services for the State’s Michigan Administrative Information Network Information DataBase Inquiry and Reporting System (MIRS) and Remittance Processing System (RPS)/Accounts Receivable System (ARS)/ Michigan Cashiering and Receivable System (MiCARS), as well as the interfaces between these systems and the State’s Michigan Administrative Information Network (MAIN) application. These services will assist State agencies in fulfilling their fiduciary responsibilities and financial control requirements and in enabling process improvement.

1.002 BACKGROUND

The receipts processing, accounts receivable and budgeting operations of currently ten (10) different agencies rely on the continued, uninterrupted use of MAIN MIRS and RPS/ARS/MiCARS and/or the interfaces between these systems and the State’s MAIN application. The applications and interfaces are necessary for these agencies to fulfill their fiduciary responsibilities and financial control requirements. All of these systems work directly with, in parallel with, or ahead of the State’s accounting system, the MAIN, and its data warehouse, the MIDB.

MIRS supports budget monitoring and forecasting using accounting actuals in the Department of Agriculture and Rural Development, Treasury, Civil Service and Technology, Management and Budget.

ARS/RPS/MiCARS supports accounts receivable and revenue receipting operations in the Departments of State, State Police, Natural Resources, Community Health and Transportation.

Interface applications which use and pass on information between the MAIN, other agency-specific applications and ARS/PRS/MiCARS have been built for the Departments of State, State Police, Community Health and Licensing and Regulatory Affairs. See section 1.103 Environment for further details.

1.100 Scope of Work and Deliverables

1.101 IN SCOPE

This Contract will secure the technical services to support MIRS and RPS/ARS/MiCARS and/or the interfaces between these systems and the MAIN application for multiple State agencies to fulfill their fiduciary responsibilities and financial control requirements.

Ongoing technical services and support are required for: Maintenance/Interface Support:

o Technical Support o Help Desk o Knowledge Transfer/Training o Documentation

Reserve Bank of Hours: o Future Enhancement Services

This initiative may be expanded to include other State Agencies whom would like to utilize the MIRS and RPS/ARS/MiCARS as well the interfaces between these systems, MAIN, and/or forthcoming supporting systems to fulfill their fiduciary responsibilities and financial control requirements and enable process improvement. A more detailed description of the services (work) and deliverables sought for this project is provided in Article 1, Section 1.104, Services and Deliverables.


126

1.102 OUT OF SCOPE

The following activities are out of scope Support of the State’s MAIN application and MAIN Hosting Hardware and COTS software Network and infrastructure management Firewall management

1.103 ENVIRONMENT

The links below provide information on the State’s Enterprise information technology (IT) policies, standards and procedures which includes security policy and procedures, IT strategic plan, eMichigan web development and the State Unified Information Technology Environment (SUITE).

Contractors are advised that the State has methods, policies, standards and procedures that have been developed over the years. Contractors are expected to provide proposals that conform to State IT policies and standards. All services and products provided as a result of this Contract must comply with all applicable State IT policies and standards. Contractor is required to review all applicable links provided below and state compliance in their response.

Enterprise IT Policies, Standards and Procedures: http://www.michigan.gov/dmb/0,1607,7-150-56355-107739--,00.html

All software and hardware items provided by the Contractor must run on and be compatible with the MDTMB Standard Information Technology Environment. Additionally, the State must be able to maintain software and other items produced as the result of the Contract. Therefore, non-standard development tools may not be used unless approved by MDTMB. The Contractor must request, in writing, approval to use non-standard software development tools, providing justification for the requested change and all costs associated with any change. The MDTMB Project Manager must approve any tools, in writing, before use on any information technology project.

It is recognized that technology changes rapidly. The Contractor may request, in writing, a change in the standard environment, providing justification for the requested change and all costs associated with any change. The State’s Project Manager must approve any changes, in writing, and MDTMB, before work may proceed based on the changed environment.

Enterprise IT Security Policy and Procedures: http://www.michigan.gov/documents/dmb/1310_183772_7.pdf http://www.michigan.gov/documents/dmb/1310.02_183775_7.pdf http://www.michigan.gov/documents/dmb/1325_193160_7.pdf http://www.michigan.gov/documents/dmb/1335_193161_7.pdf http://www.michigan.gov/documents/dmb/1340_193162_7.pdf http://www.michigan.gov/documents/dmb/1350.10_184594_7.pdf

IT Strategic Plan: http://www.michigan.gov/itstrategicplan

IT eMichigan Web Development Standard Tools: http://www.michigan.gov/documents/som/Look_and_Feel_Standards_302051_7.pdf

The State Unified Information Technology Environment (SUITE): Includes standards for project management, systems engineering, and associated forms and templates – must be followed: http://www.michigan.gov/suite

Current Specific Technical Environment Hardware

o Dell desktops and laptops (administered by DTMB Office Automation; serviced by DTMB Client Service Center and Field Services)


127

o Dell servers (administered and serviced by DTMB Customer Services Support and Technical Services)

Operating Systems o Desktop: Microsoft Windows XP and Microsoft Windows 7 o Server: Microsoft Windows 2003, MS Windows 2008

Software o Microsoft Office 2010 o Microsoft Exchange 2010 o Microsoft Internet Explorer 8 o Adobe Acrobat o Symantec

Database o Microsoft SQLServer 2005, 2008 o Oracle 10g, 11g

Firewall o Cisco

Locations o Agency Central Administrative Offices: Lansing, Dimondale, Michigan o End Users: Michigan o Hosting Centers: Lake Superior Hosting Center, Dimondale; Traverse Bay Hosting Center, Lansing

Development tools o Microsoft .Net 3.x o Java o ASP.NET 4.0

Browser o Microsoft Internet Explorer 8

Reporting tools o Microsoft Access 2010 o Crystal Reports o SQL Server Reporting Services o Business Objects

Interfaces o Department of State STAR: Stored procedures and schedule tasks that process referrals to the Department of

Treasury for collection. ARS flags delinquent invoices for referral and tracks payments received from Treasury collections. This module has a reconciliation system.

UCC: a visual basic application with associated stored procedures that interface ARS to MDOS’s Uniform Commercial Code system to invoice for fees associated with the UCC filings. Invoices are created in ARS.

Record Lookup: a Visual Basic.net system with associated stored procedures and schedule tasks that enables MDOS to retrieve and bill for Driver and Vehicle Records maintained on its central system. The system produces the record for mailing invoices to the customer via ARS. Revenue is posted to Record Lookup invoice records via the RPS.

Credit Card: part of ARS/RPS web services and stored procedures interfacing directly to the State’s Centralize Electronic Payment Authorization System (CEPAS) hosted by First Data Government Solutions (FDGS) to record and validate a credit card payment at MDOS’ cashier window.

IRP: part of ARS/RPS web services and stored procedures interfacing MDOS’ IRP system to record IRP filing, create invoices in ARP and to record revenue in PRS. The system creates “non sufficient funds” invoices when credit card payments are denied and/or checks are returned.

o Michigan State Police Crash: A set of procedures and schedule tasks which interacts with the Department of

Transportation to identify crash reports requested by the county law enforcement agencies,


128

billing for the requests and posting payments back to the Crash system. The application also maintains the customer (agencies) for billing on an Oracle database

LEIN: A set of procedures which interact with the MSP’s LEIN database to identify and bill for MSP provided items and services to criminal justice agencies. The application also maintains the customer (agency) for billing as well as billing cycles and fee structure for the various items and services.

SmartScan: A Visual Basic program that interacts with MSP’s Smartscan to identify inventory information and to create transactions for MAIN

CCW/Alias: part of the ARS/RPS stored procedures and schedule tasks which interacts with the MSP’s CCW and Alias databases to create scheduled billing and invoices to law enforcement agencies base on legislative mandates. The application also maintains the customer (agencies) for billing

MiTrain/e-Payment: part of the ARS/RPS stored procedures and schedule tasks which interacts with MSP external vendor’s Training system. The application provides rosters, schedules facilities and provides financial analysis of the conference. The system also interacts with ARS/RPS and CEPAS to allow the customer to pay either by credit card or to generate an invoice for future Payment. The e-Payment component is an interface that interacts with ARS/RPS and CEPAS that allows a customer to pay for invoices via credit card or EFT

CPLR: A set of procedures which interacts with the MSP’s CPLR and Alias databases to create scheduled billing and invoices to law enforcement agencies base on legislative mandates. The application also maintains the customer (agencies) for billing

o Community Health PPRS: This is a set of .Net web services and stored procedures which communicates payment

information from MiCARS to TPL’s Health recovery system (TED) and receives associated journal voucher and refund request information from TED and transmits the information to MAIN

PCRS: a set of web services and stored procedures which communicates payment information from MiCARS to TPL’s Court Originated Liability operations and receives associated journal voucher and refund request information from TED and transmits the information to MAIN

QAA: Imbedded in DCH’s MiCARS system, this allows MDCH to maintain QAA customers (Nursing homes) and to establish billing cycles, and rates for creating invoices on a scheduled basis

CEPAS: A set of procedures and programs that interfaces with the Department of Treasury’s CEPAS system for a log file containing credit card and EFT payments received for the day. The system reconciles transactions and posts the transactions to MiCARS for transmission to MAIN

CHAMPS: a set of web services and stored procedures which communicates payment information from MiCARS to CHAMPS and receives associated journal voucher and refund request information from CHAMPS and transmits the information to MAIN

DMS: A set of procedures which allows MiCARS to store and retrieve documents from MDCH’s document management system (Filenet)

EMS: an Visual Basic Access-Oracle database application developed jointly by the EMS section and Kunz, Leigh and Associates to license and inspect facilities and EMS vehicles in the State of Michigan. The system is used to generate renewal applications for all of the currently licensed facilities and vehicles, print State licenses, produce delinquent letters 30 and 60 days past due and provide queries and reports of facility, vehicle and inspection information. This system is also used to track Inspection results and notify the facility of Critical Non Compliant and Non Compliant conditions. By using code values for inspection violations, the EMS department is able to track trends and pro-actively work with the facility to correct the conditions. The EMS system interacts directly with the MiCARS tables to create invoices.

ASAP: A set of web services and stored procedures which communicates payment information from MiCARS to ASAP(an external vendor developed application), and receives associated journal voucher and refund request information from ASAP and transmits the information to MAIN

o Licensing and Regulatory Affairs


129

Radiation Safety Facility Engineering – Projects/Facilities: tracks registration and inspection information for radiation facilities and machines registered in the State of Michigan. The system supports automated invoice generation for registration and inspection fees. Facility/Machine Inspections: Radiation Safety performs scheduled inspections of

facilities and machines. The inspector notifies the facility immediately if there is a non-compliant issue. This will provide a history for the facility. A facility that is found to be non-compliant cannot receive a new license until they are brought into compliance. A follow-up inspection may occur after 60 days of the initial inspection.

File Maintenance: These screens are used to create and maintain facility, machine, RAM, physicist, and lookup table information.

Renewals and Certificates: The Radiation Safety system generates renewal applications for its facilities annually. At the beginning of each month the Radiation Safety system generates renewal applications for facilities that expire at the end of the month. When the renewal applications are generated, the system will calculate the expected amount due for the facility and all of its active machines. The system will generate a renewal form and the expected amount due. The amount due will be stored in an invoice table with the corresponding detail records. When payment has been received, the Radiation Safety system will generate the official State of Michigan certificate, which lists the facility information as well as all of the active machines and the expiration date of the certificate. Whenever machines are added or removed from the facility a new copy of the certificate should be generated. If payment is not received the Radiation Safety system generates a expiration notice, stating that that facility license is removed.

Inspection Planning Reports: This module displays inspection history, so that inspections can be scheduled as necessary.

Reports: There are two options in the report module: Inspection and Radiation Machine. This module provides various reports pertaining to both inspection and machine activities and facility information.

Queries: This module searches the Radiation Safety System based on criteria provided by the user.

Account Receivable: This module allows the user to generate and print invoices. The module also provides making for corrections and adjustments to invoices. Payment corrections transfer monies from invoice to invoice, revenue to invoice, invoice to revenue.

Incident: This module provides a means of recording accidents or unusual activity that has occurred in a facility. Online Module The system was enhance to provide web-based processes to allow a customer to file for new registrations, update current machine information and to pay for their registration via credit card and or EFT interfacing with CEPAS.

Interface with C3: The system was modified to interface with LARA’s C3 system with the recent agency reorganizations. Core modules are Visual Basic-Oracle database, Online modules are Java-Oracle database

Facility Engineering Projects: Allows for on-line license/registration application entry and maintenance of basic organizational and/or registration data supporting both HFES and RSS, via the internet. Allows organizations to track the status of the license application process and respond to any requests for additional information that may be required via the internet, for both HFES and RSS. Provides interfaces to CEPAS for acceptance of EFT and/or credit card-based payments. Allows licenses/registrations to be issued electronically, in a paperless fashion, as appropriate, for both HFES and RSS. Provides basic linkages within the MiTAPS system to the internet portals supporting the new HF&S System and to RSDS. (Applicants/registrants will not have direct access to the RSDS system, but will have access to new online application entry and renewal functions.). Interface to the Certificate of Need (CON) system for data verification and consolidated facility.


130

Facilities Management System: A web based application used to synchronize facility data with the Federal Government's Aspen Central Office (ACO) System. It was written to replace the Care*Net Facility Module. State users make updates to facility data to override information received from ACO as well as to track the history and types of the number of beds present in the system. The FMS system consists of a Java based web front end and an Oracle based web back end. The system pulls down ACO created facilities on a nightly basis and synchronizes information. This facility data is used by the Certificate of Need and HFES Applications on a read-only basis.

Other systems/applications requiring integration

o MI Administrative Information Network (MAIN) and MAIN Inquiry and Reporting Database RPS/ARS/MiCaRS and MIRS are subsidiary ledgers to MAIN. Detail transactions are

summarized and transmitted to MAIN. As such, much of MAIN’s processing logic is embedded within the code of the RPS/ARS/MiCaRS system to ensure that transactions are processed correctly in MAIN and result in the correct GL accounts.

o Michigan Information Database (MIDB) MIRS is based on the MIDB which reflects the universe of detail transactions within the MAIN

system. RPS/ARS/MiCaRS relies on information from MIDB to keep lookup tables and coding up to

date. This information is imported periodically (varies from agency to agency) into the system. o Future agency applications

The Contractor will support the State’s periodic upgrades to the State’s standard software portfolio in accordance with Contractor’s support timelines, e.g. Microsoft Office 2010, Windows 7, SQLServer 2008, Oracle 11g

The Contractor will support the State’s periodic upgrades to legacy application systems, e.g. MAIN application, MI DataBase which impacts the application’s supporting software and unique interface programs.

1.104 Work And Deliverable The Contractor will provide maintenance support for agencies that rely on the continued, uninterrupted use of MAIN MIRS and RPS/ARS/MiCARS and/or the interfaces between these systems and the State’s MAIN application including enhancements done to existing applications and support all new applications, interfaces, and/or functionality developed for MIRS and RPS/ARS/MiCARS. The Contractor will maintain the secure collection, transmission, maintenance, and reporting of sensitive information using DTMB approved technologies and software.

Maintenance/Interface Support: Annual Maintenance/Interface Support includes, Technical, Help Desk, Knowledge Transfer/Training and Documentation services as a flat-fixed annual rate; see Appendix A - Cost Tables. The following tasks and deliverables are contemplated by the State at this time, but are not a complete list that may be requested of the Contractor. The number of projects will vary throughout the Contract period as system changes occur, as will the required tasks and deliverables for each program. The Contractor will do all things necessary for, or incidental to, complete and successful delivery of services as they relate to MIRS, RPS/ARS/MiCARS applications, and supporting software and/or interfaces.

1. Technical Support Break Fix and Upgrades Maintenance support is available 7:00 a.m. to 5:00 p.m. Eastern Time on all State business days

with escalation as necessary to senior technical/engineering staff, and then to higher management and/or senior management. Calls for service will be returned within 1 hour.

o Initial contact will be by telephone or e-mail. Contractor will provide a web-based issue management tool for State staff to request technical

support 24 x 7 x 365. Requests after normal business hours, Contractor will contact the submitter within the first hour of the following business day.


131

Proposed resolutions will be provided within the following timeframes: o 2 hours for issues logged as “Blocker”—system is unavailable o 4 hours for issues logged as “Critical”—a user cannot complete the day’s work o 8 hours for issues logged as “Major”—a loss of functionality; however, there is a workaround

If the State and Contractor deems necessary, Contractor will perform on-site maintenance services. Provide break fix and upgrade support throughout the lifecycle of all maintenance projects. Work

with DTMB staff to resolve software application errors. Provide system concept of operations. Provide application support through any implementation’s SLC phases up to and including post-

implementation metrics reporting. All maintenance is performed by qualified personnel familiar with the hardware Perform gap analysis. Track maintenance team’s progress, predict delays, and monitor and control maintenance systems

initiatives. Plan, implement and support future releases.

o All future software updates and system enhancements applicable to system modules licensed that are of the same code base.

Implement software, software fixes and software changes according to the standard procedures of the State.

Support is provided for superseded releases and back releases still in use by the State. For the first year and all subsequent Contract years, the following services are provided for the

current version and one previous version of any software provided with the deliverables, commencing upon installation of the deliverables or delivery of the Software:

o Error Correction. If an error occurs in production, a fix will be made to correct the error after it has been identified. The State will be notified of any error corrections made.

o Material Defects. The State will be notified of any material errors or defects in the deliverables known, or made known to Contractor from any source during the Contract term that could cause the production of inaccurate, or otherwise materially incorrect, results and shall initiate actions as may be commercially necessary or proper to effect corrections of any such errors or defects.

o Updates. All new releases and bug fixes (collectively referred to as “Changes”) for any software deliverable developed or published by Contractor and made generally available to its other customers at no additional charge will be provided to the State at no additional charge.

Ensure that all services and support are delivered in a manner that meets federal, state and court ordered requirements, including software version and security patches.

o Upgrades and new versions to the system that affect end-user functionality will be at no additional cost to the State.

o The State will be provided with information on software problems encountered at other locations, along with the solution to those problems, when such information is relevant to State software.

Work with the State to adhere to all change control standards and procedures, including Request For Change (RFC) submitted to the Local Change Advisory Board (LCAB) and, if necessary, the Enterprise Change Advisory Board (ECAB) if multiple agencies are/could be impacted during the implementation.

o Submissions will occur before every release to production, or if a production break fix is needed.

o All problems will be fixed in the development environment, tested in the QA environment (not in the production environment) and released as part of the next production release using the standard RFC processes run by the agency’s LCAB and the ECAB if multiple agencies share the production environment. . All releases to production will be handled by DTMB and the Contractor will follow all State of Michigan policies, standards, and procedures. When an outage or bug is identified, the Contractor will follow the process listed

below:


132

i. Develop – After the problem is identified, a ticket will be entered in the Contractor’s defect tracking system. Once a ticket is entered, the lead developer on the project will fix the problem.

ii. Test - After development has occurred, the fix will be moved to the QA environment and tested by State staff for verification.

iii. Release – Once the problem has been fixed and tested, it is deployed in the next scheduled release. If required by the agency, an RFC will be filled out and submitted to the appropriate advisory board.

2. Help Desk Support

The Help Desk is designed to support production systems and defects resulting from, and identified during, production operations. Level 1 Support Help desk support is available 7:00 a.m. to 5:00 p.m. Eastern Time on all State business days with

escalation as necessary to senior technical/engineering staff, and then to higher management and/or senior management. Help desk staff will respond to the requestor within one (1) hour of receiving the request.

o Initial contact will be by telephone or e-mail. o Help desk staff will log any and all calls. o An on-site visit will be accomplished within 4 hours or the call – if needed.

Contractor will provide a web-based issue management tool for State staff to request technical support 24 x 7 x 365. Requests after normal business hours, Contractor will contact the submitter within the first hour of the following business day.

All problem calls will be entered into the Contractor’s helpdesk system. Reports will be made available to the agency using the applications and to DTMB at least quarterly,

and on an as needed basis. The following will be supported by the Help Desk:

o Errors in the application. (Errors are identified as program logic that does not operate per the design logic of the MIRS,RPS/ARS/MiCARS and Interface Design Reports.)

o Questions related to the use of the applications. o Data Fixes - Help in correcting production data where data problems resulted from application

errors identified earlier or from production outages that the application did not handle correctly. o Migration to new releases of desktop operating Systems. o Integration of Minor Changes to MAIN - “Minor” changes are characterized by requests under

200 hours. An example would be interface file edits. o Migration to new servers. o Migration to new frameworks.

Defects are triaged based on their impact on the State’s operations and classified as follows: o Tier 1 Defects – Have an immediate impact on production operations which negatively impact

the validity of data, or the ability to complete critical operations. o Tier 2 Defects – Have a time sensitive impact on production operations which requires an

emergency fix before the normal release schedule. o Tier 3 Defects – Need to be corrected but can be grouped as part of the normal release

schedule for the production application. All production applications will have a published release schedule for correcting system defects.

The frequency of the schedule may vary depending on the stability of the system and the interaction with any development activities. Target service levels are: o Low volume defect applications – Quarterly Releases o High volume defect application – Bi-monthly Releases o Applications with development efforts – Releases will be integrated with development releases

where possible.


133

Problem calls and subsequent work which result from the Department not migrating a release to production in a timely manner will be designated as Level 2.

3. Knowledge Transfer/Training

Contractor will perform on and off site technical and system training to state staff on current and future platform issues, applications, supportive software and interfaces at no additional cost to the State. This includes, but not limited to: Provide transition support to DTMB staff for all Contractor supported implementations and solutions

o Provide necessary training in order to transfer the support of the requested Contractor’s application.

o Provide a plan that will lay out a sequence of events where the Contractor provides training to DTMB staff and assists in implementing the solution within other area and in overseeing DTMB staff as they implement other areas.

Provide both instructor-led classroom training sessions and one-on-one training opportunities for current and future agencies.

Training needed due to upgrades and new versions to the system that affect end-user functionality (e.g. classroom or online training, training flier, release features, etc.)

o Additional testing and/or training will be performed when DTMB is upgrading versions of software that affect any existing Contractor’s applications covered under this contract.

4. Documentation

While the resources may work closely with DTMB and Agency staff, they are still required to provide documentation for all work that they do, which describes both what was done and why it was done in that fashion for current and future work at no additional cost to the State. The Contractor will create and maintain documentation that meets the State’s SUITE Methodology for all project work that is planned and accomplished during the project life cycle. All manuals, plans, reports and other documentation provided become the property of the State.

1. A minimum of two (2) copies of the following documentation in an electronic format, online and

in hard copy will be provided by the Contractor of the following documentation which includes, but is not limited to: User and Technical Manuals (procedures to monitor/maintain the system, Notification Plan,

System Administration Guide, etc.) Data Element Dictionary. Operations Manual. End User Guide. Training Materials.

2. The following documentation will be provided by the Contractor for all modules and program

development: Requirements, business workflow diagrams, issues, use cases, user-interface mockups and

problem resolution. Business operations documentation. Design architecture, technical specifications, system-wide documentation. Baseline End-User training manuals to be used as a basis for “User Manuals” and online

help. Installation procedure. Module configuration documents sufficient for configuration maintenance purposes. Testing scripts. Specification documentation. Production migration. Business operations documentation. Business Work Flow document.


134

3. All updates of documentation during the term of the Contract, software licenses and maintenance agreements.

4. The documentation of components, features, and use of the hardware/software shall be detailed such that resolution of most problems can be determined from the documentation, and most questions can be answered.

5. All system, operational, user, change, and issue documentation must be available in electronic format, published to an intranet website, accessible to State users, updated regularly, with unique numerical identifiers for each section and be consistent with the most current version of the application(s) and three (3) previous versions.

6. All system, operations, user, change and issue documentation is to be organized in a format, which is approved by the State and facilitates updating and allows for revisions to the documentation to be clearly identified including the three (3) previous versions.

7. The Contractor must develop and submit for State approval complete, accurate, and timely system, operations, and user documentation.

8. The Contractor must notify the State of any discrepancies or errors outlined in the system, operations, and user documentation.

9. If DTMB decides to assume the support of a Contractor’s application, the Contractor will provide the necessary documentation in order to transfer the support of the requested Contractor’s application. The Contractor will also provide a documented plan of the transition activities.

Reserve Bank of Hours Future enhancements may be required based on Federal and State requirements. See Appendix A- Cost Tables for the value of spending authority for future enhancement services initially added to the Contract.

The State reserves the right to add additional spending authority to the Contract. The State is not obligated to execute the contract for the full amount of spending authority for future enhancements. These services may be used by other State Agencies whom would like to utilize the MIRS and RPS/ARS/MiCARS as well the interfaces between these systems, MAIN, and/or forthcoming supporting systems to fulfill their fiduciary responsibilities and financial control requirements and enable process improvement.

Future enhancement services may only be initiated upon mutually agreed and executed individual Statement(s) of Work (SOW) between the Contractor and the State. Once agreed to, the Contractor must not be obliged or authorized to commence any work to implement a SOW until authorized via a purchase order issued against this contract.

Assigned tasks will vary according to the need that exists at any given time. Resources will work under the direction of DTMB Customer Services, in partnership with agencies and DTMB cross-matrix teams to understand technical and business demands. Coordination and involvement with the appropriate State staff will take place as required.

The following is an example of the activities that may fall within the reserve bank of hours.

System enhancements/scope modifications include changes to the system that are necessary to meet:

a. New State policy requirements, b. New Federal regulations, or c. New technology requested by the State

The Contractor must be able to respond with costs and timelines to all requests to modify the MIRS and RPS/ARS/MiCARS as well the interfaces between these systems, MAIN, and/or forthcoming supporting systems to meet future needed functionality.

A. Requirement Gathering – Contractor may assist DTMB in documenting (gathering, verifying and/or validating) functional, technical and design requirements

B. Application Adjustments & New Development - Contractor may provide the ability to suggest changes or new development work of the MIRS and RPS/ARS/MiCARS.


135

C. Interoperability Development with Other Applications - Contractor may provide the ability to request integrations or interoperability with other products or services of the MIRS and RPS/ARS/MiCARS.

D. System Interface Adjustments and New Interfaces – Contractor may provide the ability to request changes or customizations to the application user interface of the MIRS and RPS/ARS/MiCARS.

E. Contractor may provide 24 X 7 X 365 technical and/or helpdesk support.

1.200 Roles and Responsibilities

1.201 CONTRACTOR STAFF, ROLES, AND RESPONSIBILITIES

A. Contractor Staff The Contractor will provide sufficient qualified staffing to satisfy the deliverables of this Article 1 Statement of Work. Contractor must provide a list of all subcontractors, including firm name, address, contact person, and a complete description of the work to be contracted. Include descriptive information concerning subcontractor’s organization and abilities.

The Contractor must replace all employees whose work was found to be unsatisfactory as determined by the DTMB project manager within five (5) business days of notification.

The Contractor will update when changed, an organizational chart/responsibility matrix as Attachment 2 indicating lines of authority for personnel involved in performance of this Contract and relationships of this staff to other programs or functions of the firm. Single Point of Contact (SPOC) John K. Leigh will be the SPOC for this contract. The duties of the SPOC shall include, but not be limited to:

supporting the management of the Contract, facilitating dispute resolution, and advising the State of performance under the terms and conditions of the Contract.

The State reserves the right to require a change in the current SPOC if the assigned SPOC is not, in the opinion of the State, adequately serving the needs of the State. Key Personnel The State reserves the right to designate Key Personnel to be provided by the Contractor, as part of individual SOW’s. The State reserves the right to interview all Key Personnel and to approve their assignment.

B. Work Requirements 1. Location of Work

a. On-site work will be performed at a State Authorized facilities located in the downtown Lansing area, Michigan or nearby cities. There may be occasion to interact with agency staff in Detroit, MI.

b. Remote work may be performed at the discretion of the State. NO work will be performed offshore.

2. Hours of Operation:

a. Normal State working hours are 8:00 a.m. to 5:00 p.m. EST, Monday through Friday, with work performed as necessary after those hours to meet project deadlines. No overtime will be authorized or paid.

b. The State is not obligated to provide State management of assigned work outside of normal State working hours. The State reserves the right to modify the work hours in the best interest of the project.

c. Contractor shall observe the same standard holidays as State employees. The State does not compensate for holiday pay.


136

3. Travel:

a. No travel or expenses will be reimbursed. This includes travel costs related to training provided to the State by Contractor.

b. Travel time will not be reimbursed. c. The State is not responsible for providing the use of vehicles for the Contractor. d. The State is not responsible for providing housing accommodations to the Contractor.

4. Additional Security and Background Check Requirements:

Before any Contractor staff may have access to State facilities and systems, they must submit to an enhanced level of background checks. The following checks will be required of the successful Contractor for any staff assigned to this project, and results will be used to determine Contractor staff eligibility for working within State facilities and systems.

The Contractor must present certifications evidencing satisfactory Michigan State Police

Background checks, ICHAT (Internet Criminal History Access Tool) and drug tests for all staff identified for assignment to this project.

In addition, proposed Contractor personnel will be required to complete and submit an RI-8

Fingerprint Card for the National Crime Information Center (NCIC) Finger Prints, if required by project.

Contractor will pay for all costs associated with ensuring their staff meets all requirements.

1.202 STATE STAFF, ROLES, AND RESPONSIBILITIES

The State may provide the following resources for the Contractor’s on-site use, as determined for a specific engagement, through individual Statements of Work. These may include: Work space Minimal clerical support Desk Printer Access to copiers and fax machine Access to the State network Other equipment deemed necessary by DTMB to perform tasks identified in this contract. The Contractor is responsible for the return of all State issued equipment in the same condition as when provided by the State, reasonable wear and tear expected, upon Contractor staff release from the project. The State reserves the right to inspect and scan any equipment supplied by the Contractor that will be connected to the State’s network. Project Managers The State will designate Project Managers for specific Agency engagements. These State resources will be empowered to:

Resolve project issues in a timely manner Review project plan, status, and issues Resolve deviations from project plan Provide acceptance sign-off Utilize change control procedures Ensure timely availability of State resources Make key implementation decisions, as identified by the Contractor’s project manager, within 48-hours of

their expected decision date Provide State facilities, as needed


137

Coordinate the State resources necessary for the project Facilitate coordination between various external Contractors Facilitate communication between different State departments/divisions Provide acceptance and sign-off of deliverable/milestone Review and sign-off of timesheets and invoices Resolve project issues Escalate outstanding/high priority issues Conduct regular and ongoing review of the project to confirm that it meets original objectives and

requirements Document and archive all important project decisions Arrange, schedule and facilitate State staff attendance at all project meetings

Contract Compliance Inspector MDTMB will provide a Contract Compliance Inspector who will be responsible for overseeing all services performed under the Contract and coordinating with the Agencies. The State’s Contract Compliance Inspector will provide the following services:

Escalate outstanding/high priority issues Resolve program issues Utilize change control procedures Conduct regular and ongoing review of the Contract to confirm that it meets original objectives and

requirements Document and archive all important Contract decisions Facilitate communication with State project and operational staff Support the management of the Contract

Contract Compliance Inspector will be: Name Agency/Division Title David Borzenski MDTMB Business Relationship Manager

1.300 Project Plan

1.301 PROJECT PLAN MANAGEMENT

Project Plan Specific project plan requirements may be defined within individual SOW’s. Contract Kick-Off Meeting Upon 14 calendar days from execution of the Contract, the Contractor may be required to attend an orientation meeting to discuss the content and procedures of the Contract. The meeting will be held in Lansing, Michigan, at a date and time mutually acceptable to the state and the Contractor. The state shall bear no cost for the time and travel of the Contractor for attendance at the meeting. Performance Review Meetings The State may require the Contractor to attend meetings as needed, to review the Contractor’s performance under the Contract. The meetings will be held in Lansing, Michigan or by teleconference, as mutually agreed by the State and the Contractor. The State shall bear no cost for the time and travel of the Contractor for attendance at the meeting.


138

Program Control 1. The Contractor will carry out this program under the direction and control of DTMB. The DTMB project

manager will review progress reports and will review and approve payments. 2. The Contractor will manage projects in accordance with the State Unified Information Technology

Environment (SUITE) methodology, which includes standards for project management, systems engineering, and associated forms and templates which is available at http://www.michigan.gov/suite

a. Contractor will use an automated tool for planning, monitoring, and tracking the Contract’s progress and the level of effort of any Contractor personnel spent performing Services under the Contract. The tool shall have the capability to produce:

i. Staffing tables with names of personnel assigned to Contract tasks. ii. Project plans showing tasks, subtasks, deliverables, and the resources required and

allocated to each (including detailed plans for all Services to be performed within the next sixty (60) calendar days, updated semi-monthly).

iii. Updates must include actual time spent on each task and a revised estimate to complete.

iv. Graphs showing critical events, dependencies and decision points during the course of the Contract.

b. Any tool(s) used by Contractor for such purposes must produce information of a type and in a manner and format that will support reporting in compliance with the State standards.

3. The DTMB project manager shall have contact as needed with individual contract employees for the purpose of reviewing progress and providing necessary guidance in solving problems which arise. The objective of this step is to ensure that the DTMB project manager is promptly informed of issues and risks that confront the Contractor employees throughout the contract.

4. All project assignments and tasks will be undertaken only upon the prior written authorization of the DTMB project manager. The written authorization will include a definition of tasks, deliverables, estimated hours, fixed unit price per hour for each personnel classification, extended price for each personnel classification, maximum price for the authorization, and authorization expiration date. Hours authorized for each task may not be exceeded without a change order issued by the DTMB project manager. If the Contractor employees identify tasks that they anticipate may exceed the estimated amounts, they should notify the DTMB project manager so that any work stoppage may be avoided.

1.302 REPORTS

Specific reporting requirements will be defined within individual SOW’s. Reporting formats must be submitted to the State’s Project Manager for approval within 10 business days after the execution of the contract.. Once both parties have agreed to the format of the report, it shall become the standard to follow for the duration of the contract. At minimum the status reports shall include: Dates of the week covered (daily breakdown by project) Contractor name DTMB manager name Contract name P.O. number For each project on which the resource worked during the week:

o Project name o Work authorization number o Number of hours worked on the project for each business day of the week o Total number of hours worked on the project during the week

Total number of hours being billed for the week DTMB and/or project manager signature and date Contractor signature and date

The status report may include the following items for which the resource has worked: Project name Milestones/deliverables completed


139

Tasks accomplished Next steps Potential issues/risks

1.400 Project Management

1.401 ISSUE MANAGEMENT

An issue is an identified event that if not addressed may affect schedule, scope, quality, or budget. The Contractor shall maintain an issue log for issues relating to the provision of services under this Contract. The issue management log must be communicated to the Contract Compliance Inspector and the applicable SOM Project Manager on an agreed upon schedule, with e-mail notifications and updates. The issue log must be updated and must contain the following minimum elements:

1. Description of issue. 2. Issue identification date. 3. Responsibility for resolving issue. 4. Priority for issue resolution (to be mutually agreed upon by the SOM and the Contractor). 5. Resources assigned responsibility for resolution. 6. Resolution date. 7. Resolution description.

Once the Contractor or the SOM has identified an issue, the Contractor shall follow these steps:

1. Immediately communicate the issue in writing to the SOM Project Manager. 2. The Contractor will log the issue into an issue tracking system. 3. Identify what needs to be done and resources needed to correct the issue. 4. Receive approval from the SOM Project Manager for appropriate action. 5. Keep SOM Project Manager and appropriate parties informed on status of issue based on frequency

established by the SOM Project Manager. 6. At least monthly provide a listing of all issues with their current status, deadlines to correct and actual

dates of completion that have occurred to the SOM Project Manager. Issues shall be escalated for resolution from level 1 through level 2, as defined below:

Level 1 – Project Manager Level 2 – Contract Compliance Inspector

1.402 RISK MANAGEMENT

A risk is an unknown circumstance or event that, if it occurs, may have a positive or negative impact on the project. The Contractor is responsible for establishing a risk management plan and process, including the identification and recording of risk items, prioritization of risks, definition of mitigation strategies, monitoring of risk items, and periodic risk assessment reviews with the SOM. A risk management plan format shall be submitted to the SOM for approval within twenty (20) business days after contract signing. The risk management plan will be developed during the initial planning phase of the project, and be in accordance with the SOM PMM methodology. Once both parties have agreed to the format of the plan, it shall become the standard to follow for the duration of the contract. The plan must be updated bi-weekly, or as agreed upon. The Contractor shall provide the tool to track risks. The Contractor will work with the SOM and allow input into the prioritization of risks.


140

The Contractor is responsible for identification of risks for each phase of the project. Mitigating and/or eliminating assigned risks will be the responsibility of the Contractor. The SOM will assume the same responsibility for risks assigned to them. The project risk log will be updated by the Contractor, contain the following minimum elements and be mutually agreed upon by the Contractor and State:

1. Description of risk 2. Risk identification date 3. Responsibility for mitigating risk 4. Priority for risk mitigation 5. Resources assigned responsibility for mitigation 6. Mitigation date 7. Mitigation description

1.403 CHANGE MANAGEMENT

Change management is defined as the process to communicate, assess, monitor, and control all changes to system resources and processes. The State also employs change management in its administration of the Contract. The Contractor must employ change management procedures to handle such things as “out-of-scope” requests or changing business needs of the State while the project is underway. Contractors who provide products or services prior to the issuance of a project change order (which may require a Contract Change Notice by the DTMB-Procurement) risk non-payment for the out-of-scope/pricing products and/or services. The Contractor will employ the change control methodologies to justify changes in the processing environment, and to ensure those changes will not adversely affect performance or availability.

1.500 Acceptance

1.501 CRITERIA

In addition to Section 2.250 Approval of Deliverables, Acceptance Criteria will be defined within individual SOW’s.

1.600 Compensation and Payment

1.601 COMPENSATION AND PAYMENT

Method of Payment Cost Table (Appendix B) Table 2 Annual payment shall be made on a firm, fixed cost basis for Maintenance/Interface Support (including Technical Support, Help Desk, Knowledge Transfer/Training and Documentation). Should an agency discontinue usage of an application or an interface, the State’s payable amount for Maintenance/Interface Support shall be prorated at 1/30th of the monthly maintenance/interface charges for each calendar day. Cost Table (Appendix B) Table 3 A Reserved Bank of Hours for services and specifying not-to-exceed hourly rates based on skill sets that can be utilized for future work projects. The State reserves the right to determine whether payment shall be made on a not to exceed firm fixed-hourly rate basis, or on completion and acceptance of specified deliverables for future enhancements. Future enhancement services may only be initiated upon mutually agreed and executed individual Statement(s) of Work (SOW) between the Contractor and the State. Once agreed to,


141

the Contractor must not be obliged or authorized to commence any work to implement a SOW until authorized via a purchase order issued against this contract. The State shall have the right to hold back an amount equal to percent 5% of all amounts invoiced by Contractor for specified deliverables for future enhancements.

Each Statements of Work (SOW) will include:

1. Background 2. Project Objective 3. Scope of Work 4. Deliverables 5. Acceptance Criteria 6. Project Control and Reports 7. Specific Department Standards 8. Cost/Rate 9. Payment Schedule

10. Project Contacts 11. Agency Responsibilities 12. Location of Where the Work is to be performed 13. Expected Contractor Work Hours and Conditions

The Contractor will not be paid for any costs attributable to corrections of any errors or omissions that have been determined by the DTMB Project Manager to be caused by the Contractor. Payments will be paid no more than monthly. Prices quoted will be firm for the entire length of the Contract. For any options to renew (see Section 2.002), prices may not be increased by more than the previous year’s Consumer Price Index (CPI) or 3%, whichever is lower.

The selected Contractor will be required to submit an Administrative Fee (see Section 2.031) on all payments remitted under the Contract. Travel The State will not pay for any travel expenses, including hotel, mileage, meals, parking, etc. Travel time will not be reimbursed. Notification of Price Reductions If Contractor reduces its prices for any of the services during the term of this Contract, the State shall have the immediate benefit of such lower prices for new purchases. Contractor shall send notice to the DTMB Procurement Buyer with the reduced prices within fifteen (15) Business Days of the reduction taking effect.

Issuance of Purchase Orders (PO) Contractor shall not be obliged or authorized to commence any work orders until authorized via a PO issued against this Contract. Contractor shall perform in accordance with this Contract, including the Statements of Work/Vendor Proposal/Purchase Orders executed under it. Invoicing Contractor will submit properly itemized invoices to

DTMB – Financial Services Accounts Payable P.O. Box 30026 Lansing, MI 48909 or [email protected]


142

Invoices must provide and itemize: Contract number; Purchase Order number Contractor name, address, phone number, and Federal Tax Identification Number; Description of service; State Project Manager name Date(s) of delivery; Rate; Total invoice price; and Payment terms, including any available prompt payment discount. Incorrect or incomplete invoices will be returned to Contractor for correction and reissue.

1.602 HOLDBACK

The State shall have the right to hold back an amount equal to percent 5% of all amounts invoiced by Contractor for specified deliverables for future enhancements. The amounts held back shall be released to Contractor after the State has granted Final Acceptance.


143

Article 2, Terms and Conditions

2.000 Contract Structure and Term

2.001 CONTRACT TERM

This Contract is for a period of five (5) years beginning January 1st 2014 through December 31, 2019. All outstanding Purchase Orders must also expire upon the termination for any of the reasons listed in Section 2.150 of the Contract, unless otherwise extended under the Contract. Absent an early termination for any reason, Purchase Orders issued but not expired, by the end of the Contract’s stated term, shall remain in effect for the balance of the fiscal year for which they were issued.

2.002 OPTIONS TO RENEW

The parties may agree in writing to extend this Contract prior to the expiration of the Base Term, or any Renewal Term, by twelve (12) month increments (each a “Renewal Term”). The parties may not execute more than three (3) Renewal Periods at any given time. Successful completion of negotiations surrounding the terms of the extension, will be a pre-requisite for the exercise of any Renewal Term.

2.003 LEGAL EFFECT

Contractor accepts this Contract by signing two copies of the Contract and returning them to the DTMB-Procurement. The Contractor shall not proceed with the performance of the work to be done under the Contract, including the purchase of necessary materials, until both parties have signed the Contract to show acceptance of its terms, and the Contractor receives a contract release/purchase order that authorizes and defines specific performance requirements. Except as otherwise agreed in writing by the parties, the State shall not be liable for costs incurred by Contractor or payment under this Contract, until Contractor is notified in writing that this Contract or Change Order has been approved by the State Administrative Board (if required), signed by all the parties and a Purchase Order against the Contract has been issued.

2.004 ATTACHMENTS & EXHIBITS

All Attachments and Exhibits affixed to any and all Statement(s) of Work, or appended to or referencing this Contract, are incorporated in their entirety and form part of this Contract.

2.005 ORDERING

The State must issue an approved written Purchase Order, Blanket Purchase Order, Direct Voucher or Procurement Card Order to order any Services/Deliverables under this Contract. All orders are subject to the terms and conditions of this Contract. No additional terms and conditions contained on either a Purchase Order or Blanket Purchase Order apply unless they are specifically contained in that Purchase Order or Blanket Purchase Order's accompanying Statement of Work. Exact quantities to be purchased are unknown; however, the Contractor will be required to furnish all such materials and services as may be ordered during the Contract period. Quantities specified, if any, are estimates based on prior purchases, and the State is not obligated to purchase in these or any other quantities.

2.006 ORDER OF PRECEDENCE

The Contract, including any Statements of Work and Exhibits, to the extent not contrary to the Contract, each of which is incorporated for all purposes, constitutes the entire agreement between the parties with respect to the subject matter and supersedes all prior agreements, whether written or oral, with respect to the subject matter and as additional terms and conditions on the purchase order must apply as limited by Section 2.005.

In the event of any inconsistency between the terms of the Contract and a Statement of Work, the terms of the Statement of Work shall take precedence (as to that Statement of Work only); provided, however, that a Statement of Work may not modify or amend the terms of the Contract. The Contract may be modified or amended only by a formal Contract amendment.


144

2.007 HEADINGS

Captions and headings used in the Contract are for information and organization purposes. Captions and headings, including inaccurate references, do not, in any way, define or limit the requirements or terms and conditions of the Contract.

2.008 FORM, FUNCTION & UTILITY

If the Contract is for use of more than one State agency and if the Deliverable/Service does not the meet the form, function, and utility required by that State agency, that agency may, subject to State purchasing policies, procure the Deliverable/Service from another source.

2.009 REFORMATION AND SEVERABILITY

Each provision of the Contract is severable from all other provisions of the Contract and, if one or more of the provisions of the Contract is declared invalid, the remaining provisions of the Contract remain in full force and effect.

2.010 Consents and Approvals Except as expressly provided otherwise in the Contract, if either party requires the consent or approval of the other party for the taking of any action under the Contract, the consent or approval must be in writing and must not be unreasonably withheld or delayed.

2.011 NO WAIVER OF DEFAULT

If a party fails to insist upon strict adherence to any term of the Contract then the party has not waived the right to later insist upon strict adherence to that term, or any other term, of the Contract.

2.012 SURVIVAL

Any provisions of the Contract that impose continuing obligations on the parties, including without limitation the parties’ respective warranty, indemnity and confidentiality obligations, survive the expiration or termination of the Contract for any reason. Specific references to survival in the Contract are solely for identification purposes and not meant to limit or prevent the survival of any other section

2.020 Contract Administration

2.021 ISSUING OFFICE

This Contract is issued by the Department of Technology, Management and Budget, Procurement Office of State Procurement (collectively, including all other relevant State of Michigan departments and agencies, the “State”). DTMB-Procurement is the sole point of contact in the State with regard to all procurement and contractual matters relating to the Contract. The DTMB-Procurement Buyer for this Contract is:

Whitnie Zuker, Buyer Procurement Department of Technology, Management and Budget Mason Bldg, 2nd Floor PO Box 30026 Lansing, MI 48909 [email protected]

2.022 CONTRACT COMPLIANCE INSPECTOR

The Director of DTMB-Procurement directs the person named below, or his or her designee, to monitor and coordinate the activities for the Contract on a day-to-day basis during its term. Monitoring Contract activities does not imply the authority to change, modify, clarify, amend, or otherwise alter the prices, terms, conditions and specifications of the Contract. DTMB-Procurement is the only State office authorized to change, modify, amend, alter or clarify the prices, specifications, terms and conditions of this Contract. The Contract Compliance Inspector for this Contract is:


145

David Borzenski, Business Relation Manager Department of Technology, Management and Budget Hollister Bldg. 5th Floor 106 West Allegan 5th Floor Lansing, MI 48933 [email protected] (517) 241-4652

2.023 PROJECT MANAGER – SEE SECTION 1.201

2.024 CHANGE REQUESTS

The State reserves the right to request from time to time any changes to the requirements and specifications of the Contract and the work to be performed by the Contractor under the Contract. During the course of ordinary business, it may become necessary for the State to discontinue certain business practices or create Additional Services/Deliverables. At a minimum, to the extent applicable, Contractor shall provide a detailed outline of all work to be done, including tasks necessary to accomplish the Additional Services/Deliverables, timeframes, listing of key personnel assigned, estimated hours for each individual per task, and a complete and detailed cost justification. If the State requests or directs the Contractor to perform any Services/Deliverables that are outside the scope of the Contractor’s responsibilities under the Contract (“New Work”), the Contractor must notify the State promptly before commencing performance of the requested activities it believes are New Work. If the Contractor fails to notify the State before commencing performance of the requested activities, any such activities performed before the Contractor gives notice shall be conclusively considered to be in-scope Services/Deliverables and not New Work. If the State requests or directs the Contractor to perform any services or provide deliverables that are consistent with and similar to the Services/Deliverables being provided by the Contractor under the Contract, but which the Contractor reasonably and in good faith believes are not included within the Statements of Work, then before performing such Services or providing such Deliverables, the Contractor shall notify the State in writing that it considers the Services or Deliverables to be an Additional Service/Deliverable for which the Contractor should receive additional compensation. If the Contractor does not so notify the State, the Contractor shall have no right to claim thereafter that it is entitled to additional compensation for performing that Service or providing that Deliverable. If the Contractor does so notify the State, then such a Service or Deliverable shall be governed by the Change Request procedure in this Section. In the event prices or service levels are not acceptable to the State, the Additional Services or New Work shall be subject to competitive bidding based upon the specifications. (1) Change Request at State Request If the State requires Contractor to perform New Work, Additional Services or make changes to the

Services that would affect the Contract completion schedule or the amount of compensation due Contractor (a “Change”), the State shall submit a written request for Contractor to furnish a proposal for carrying out the requested Change (a “Change Request”).

(2) Contractor Recommendation for Change Requests: Contractor shall be entitled to propose a Change to the State, on its own initiative, should Contractor

believe the proposed Change would benefit the Contract. (3) Upon receipt of a Change Request or on its own initiative, Contractor shall examine the implications of the

requested Change on the technical specifications, Contract schedule and price of the Deliverables and Services and shall submit to the State without undue delay a written proposal for carrying out the Change. Contractor’s proposal shall include any associated changes in the technical specifications, Contract schedule and price and method of pricing of the Services. If the Change is to be performed on a time and


146

materials basis, the Amendment Labor Rates shall apply to the provision of such Services. If Contractor provides a written proposal and should Contractor be of the opinion that a requested Change is not to be recommended, it shall communicate its opinion to the State but shall nevertheless carry out the Change as specified in the written proposal if the State directs it to do so.

(4) By giving Contractor written notice within a reasonable time, the State shall be entitled to accept a Contractor proposal for Change, to reject it, or to reach another agreement with Contractor. Should the parties agree on carrying out a Change, a written Contract Change Notice must be prepared and issued under this Contract, describing the Change and its effects on the Services and any affected components of this Contract (a “Contract Change Notice”).

(5) No proposed Change shall be performed until the proposed Change has been specified in a duly executed Contract Change Notice issued by the Department of Technology, Management and Budget, Procurement.

(6) If the State requests or directs the Contractor to perform any activities that Contractor believes constitute a Change, the Contractor must notify the State that it believes the requested activities are a Change before beginning to work on the requested activities. If the Contractor fails to notify the State before beginning to work on the requested activities, then the Contractor waives any right to assert any claim for additional compensation or time for performing the requested activities. If the Contractor commences performing work outside the scope of this Contract and then ceases performing that work, the Contractor must, at the request of the State, retract any out-of-scope work that would adversely affect the Contract.

2.025 NOTICES

Any notice given to a party under the Contract must be deemed effective, if addressed to the party as addressed below, upon: (i) delivery, if hand delivered; (ii) receipt of a confirmed transmission by facsimile if a copy of the notice is sent by another means specified in this Section; (iii) the third Business Day after being sent by U.S. mail, postage pre-paid, return receipt requested; or (iv) the next Business Day after being sent by a nationally recognized overnight express courier with a reliable tracking system. State: State of Michigan Procurement Attention: PO Box 30026 530 West Allegan Lansing, Michigan 48909 Contractor: Kunz, Leigh & Associates 28081 Southfield Road Lathrup Village, MI 48076-2816 Either party may change its address where notices are to be sent by giving notice according to this Section.

2.026 BINDING COMMITMENTS

Representatives of Contractor must have the authority to make binding commitments on Contractor’s behalf within the bounds set forth in the Contract. Contractor may change the representatives from time to time upon giving written notice.

2.027 RELATIONSHIP OF THE PARTIES

The relationship between the State and Contractor is that of client and independent Contractor. No agent, employee, or servant of Contractor or any of its SubContractors shall be deemed to be an employee, agent or servant of the State for any reason. Contractor shall be solely and entirely responsible for its acts and the acts of its agents, employees, servants and SubContractors during the performance of the Contract.


147

2.028 COVENANT OF GOOD FAITH

Each party shall act reasonably and in good faith. Unless stated otherwise in the Contract, the parties shall not unreasonably delay, condition or withhold the giving of any consent, decision or approval that is either requested or reasonably required of them in order for the other party to perform its responsibilities under the Contract.

2.029 ASSIGNMENTS

Neither party may assign the Contract, or assign or delegate any of its duties or obligations under the Contract, to any other party (whether by operation of law or otherwise), without the prior written consent of the other party; provided, however, that the State may assign the Contract to any other State agency, department, division or department without the prior consent of Contractor and Contractor may assign the Contract to an affiliate so long as the affiliate is adequately capitalized and can provide adequate assurances that the affiliate can perform the Contract. The State may withhold consent from proposed assignments, subcontracts, or novations when the transfer of responsibility would operate to decrease the State’s likelihood of receiving performance on the Contract or the State’s ability to recover damages.

Contractor may not, without the prior written approval of the State, assign its right to receive payments due under the Contract. If the State permits an assignment, the Contractor is not relieved of its responsibility to perform any of its contractual duties and the requirement under the Contract that all payments must be made to one entity continues.

If the Contractor intends to assign the contract or any of the Contractor's rights or duties under the Contract, the Contractor must notify the State in writing at least 90 days before the assignment. The Contractor also must provide the State with adequate information about the assignee within a reasonable amount of time before the assignment for the State to determine whether to approve the assignment.

2.030 General Provisions

2.031 ADMINISTRATIVE FEE AND REPORTING

The Contractor must remit an administrative fee of one percent 1% on all payments remitted to Contractor under the Contract including transactions with the State (including its departments, divisions, agencies, offices, and commissions), MiDEAL members, and other states (including governmental subdivisions and authorized entities). Contractor must submit an itemized purchasing activity report, which includes at a minimum, the name of the purchasing entity and the total dollar volume in sales.

Itemized purchasing activity reports should be mailed to DTMB-Procurement and the administrative fee payments shall be made by check payable to the State of Michigan and mailed to:

The Department of Technology, Management and Budget Financial Services – Cashier Unit Lewis Cass Building 320 South Walnut St. P.O. Box 30681 Lansing, MI 48909

The administrative fee and purchasing activity report are due within 30 calendar days from the last day of each quarter.


148

2.032 MEDIA RELEASES

News releases (including promotional literature and commercial advertisements) pertaining to the RFP and Contract or project to which it relates shall not be made without prior written State approval, and then only in accordance with the explicit written instructions from the State. No results of the activities associated with the RFP and Contract are to be released without prior written approval of the State and then only to persons designated.

2.033 CONTRACT DISTRIBUTION

DTMB-Procurement retains the sole right of Contract distribution to all State agencies and local units of government unless other arrangements are authorized by DTMB-Procurement.

2.034 PERMITS

Contractor must obtain and pay any associated costs for all required governmental permits, licenses and approvals for the delivery, installation and performance of the Services. The State shall pay for all costs and expenses incurred in obtaining and maintaining any necessary easements or right of way.

2.035 WEBSITE INCORPORATION

The State is not bound by any content on the Contractor’s website, even if the Contractor’s documentation specifically referenced that content and attempts to incorporate it into any other communication, unless the State has actual knowledge of the content and has expressly agreed to be bound by it in a writing that has been manually signed by an authorized representative of the State.

2.036 FUTURE BIDDING PRECLUSION

Contractor acknowledges that, to the extent this Contract involves the creation, research, investigation or generation of a future RFP; it may be precluded from bidding on the subsequent RFP. The State reserves the right to disqualify any Bidder if the State determines that the Bidder has used its position (whether as an incumbent Contractor, or as a Contractor hired to assist with the RFP development, or as a Vendor offering free assistance) to gain a competitive advantage on the RFP

2.037 FREEDOM OF INFORMATION

All information in any proposal submitted to the State by Contractor and this Contract is subject to the provisions of the Michigan Freedom of Information Act, 1976 Public Act No. 442, as amended, MCL 15.231, et seq (the “FOIA”).

2.038 DISASTER RECOVERY

Contractor and the State recognize that the State provides essential services in times of natural or man-made disasters. Therefore, except as so mandated by Federal disaster response requirements, Contractor personnel dedicated to providing Services/Deliverables under this Contract shall provide the State with priority service for repair and work around in the event of a natural or man-made disaster.

2.040 Financial Provisions

2.041 FIXED PRICES FOR SERVICES/DELIVERABLES

Each Statement of Work, Vendor Proposal and/or Purchase Order issued under this Contract shall specify (or indicate by reference to the appropriate Contract Exhibit) the firm, fixed prices for all Services/Deliverables, and the associated payment milestones and payment amounts. The State may make progress payments to the Contractor when requested as work progresses, but not more frequently than monthly, in amounts approved by the State after negotiation. Contractor shall show verification of measurable progress at the time of requesting progress payments.


149

2.042 ADJUSTMENTS FOR REDUCTIONS IN SCOPE OF SERVICES/DELIVERABLES

If the scope of the Services/Deliverables under any Statement of Work issued under this Contract is subsequently reduced by the State, the parties shall negotiate an equitable reduction in Contractor’s charges under such Statement of Work commensurate with the reduction in scope.

2.043 SERVICES/DELIVERABLES COVERED

The State shall not be obligated to pay any amounts in addition to the charges specified in this Contract for all Services/Deliverables to be provided by Contractor and its SubContractors, if any, under this Contract.

2.044 INVOICING AND PAYMENT – IN GENERAL

(a) Each Statement of Work, and/or Purchase Order issued under this Contract shall list (or indicate by reference to the appropriate Contract Exhibit) the prices for all Services/Deliverables, equipment and commodities to be provided, and the associated payment milestones and payment amounts.

(b) Each Contractor invoice shall show details as to charges by Service/Deliverable component and location at a level of detail reasonably necessary to satisfy the State’s accounting and charge-back requirements. Invoices for Services performed on a time and materials basis shall show, for each individual, the number of hours of Services performed during the billing period, the billable skill/labor category for such person and the applicable hourly billing rate. Prompt payment by the State is contingent on the Contractor’s invoices showing the amount owed by the State minus any holdback amount to be retained by the State in accordance with Section 1.600.

(c) Correct invoices shall be due and payable by the State, in accordance with the State’s standard payment procedure as specified in 1984 Public Act No. 279, MCL 17.51 et seq., within 45 days after receipt, provided the State determines that the invoice was properly rendered.

(d1) All invoices should reflect actual work done. Specific details of invoices and payments shall be agreed

upon between the State and the Contractor after the proposed Contract Agreement has been signed and accepted by both the Contractor and the Director of Procurement, Department of Management & Budget. This activity shall occur only upon the specific written direction from DTMB-Procurement.

The specific payment schedule for any Contract(s) entered into, as the State and the Contractor(s) shall

mutually agree upon. The schedule should show payment amount and should reflect actual work done by the payment dates, less any penalty cost charges accrued by those dates. As a general policy statements shall be forwarded to the designated representative by the 15th day of the following month.

The Government may make progress payments to the Contractor when requested as work progresses,

but not more frequently than monthly, in amounts approved by the State, after negotiation. Contractor must show verification of measurable progress at the time of requesting progress payments.

2.045 PRO-RATION

To the extent there are Services that are to be paid for on a monthly basis, the cost of such Services shall be pro-rated for any partial month.

2.046 ANTITRUST ASSIGNMENT

The Contractor assigns to the State any claim for overcharges resulting from antitrust violations to the extent that those violations concern materials or services supplied by third parties to the Contractor, toward fulfillment of this Contract.

2.047 FINAL PAYMENT

The making of final payment by the State to Contractor does not constitute a waiver by either party of any rights or other claims as to the other party’s continuing obligations under the Contract, nor shall it constitute a waiver of any claims by one party against the other arising from unsettled claims or failure by a party to comply with this Contract, including claims for Services and Deliverables not reasonably known until after acceptance


150

to be defective or substandard. Contractor’s acceptance of final payment by the State under this Contract shall constitute a waiver of all claims by Contractor against the State for payment under this Contract, other than those claims previously filed in writing on a timely basis and still unsettled.

2.048 ELECTRONIC PAYMENT REQUIREMENT

Electronic transfer of funds is required for payments on State Contracts. Contractors are required to register with the State electronically at http://www.cpexpress.state.mi.us. As stated in Public Act 431 of 1984, all contracts that the State enters into for the purchase of goods and services shall provide that payment shall be made by electronic fund transfer (EFT).

2.050 Taxes

2.051 EMPLOYMENT TAXES

Contractor shall collect and pay all applicable federal, state, and local employment taxes, including the taxes.

2.052 SALES AND USE TAXES

Contractor shall register and remit sales and use taxes on taxable sales of tangible personal property or services delivered into the State. Contractors that lack sufficient presence in Michigan to be required to register and pay tax must do so as a volunteer. This requirement extends to: (1) all members of any controlled group as defined in § 1563(a) of the Internal Revenue Code and applicable regulations of which the company is a member, and (2) all organizations under common control as defined in § 414(c) of the Internal Revenue Code and applicable regulations of which the company is a member that make sales at retail for delivery into the State are registered with the State for the collection and remittance of sales and use taxes. In applying treasury regulations defining “two or more trades or businesses under common control” the term “organization” means sole proprietorship, a partnership (as defined in § 701(a) (2) of the Internal Revenue Code), a trust, an estate, a corporation, or a limited liability company.

2.060 Contract Management

2.061 CONTRACTOR PERSONNEL QUALIFICATIONS

All persons assigned by Contractor to the performance of Services under this Contract must be employees of Contractor or its majority-owned (directly or indirectly, at any tier) subsidiaries (or a State-approved SubContractor) and must be fully qualified to perform the work assigned to them. Contractor must include a similar provision in any subcontract entered into with a SubContractor. For the purposes of this Contract, independent Contractors engaged by Contractor solely in a staff augmentation role must be treated by the State as if they were employees of Contractor for this Contract only; however, the State understands that the relationship between Contractor and SubContractor is an independent Contractor relationship.

2.062 CONTRACTOR KEY PERSONNEL

(a) The Contractor must provide the State with the names of the Key Personnel. (b) Key Personnel must be dedicated as defined in the in the contract or any Statement of Work issued under

it for the full duration specified. (c) The State shall have the right to recommend and approve in writing the initial assignment, as well as any

proposed reassignment or replacement, of any Key Personnel. Before assigning an individual to any Key Personnel position, Contractor shall notify the State of the proposed assignment, shall introduce the individual to the appropriate State representatives, and shall provide the State with a resume and any other information about the individual reasonably requested by the State. The State reserves the right to interview the individual before granting written approval. In the event the State finds a proposed individual unacceptable, the State shall provide a written explanation including reasonable detail outlining the reasons for the rejection.

(d) Contractor must not remove any Key Personnel from their assigned roles on the Contract without the prior written consent of the State. The Contractor’s removal of Key Personnel without the prior written consent of the State is an unauthorized removal (“Unauthorized Removal”). Unauthorized Removals does not


151

include replacing Key Personnel for reasons beyond the reasonable control of Contractor, including illness, disability, leave of absence, personal emergency circumstances, resignation or for cause termination of the Key Personnel’s employment. Unauthorized Removals does not include replacing Key Personnel because of promotions or other job movements allowed by Contractor personnel policies or Collective Bargaining Agreement(s) as long as the State receives prior written notice before shadowing occurs and Contractor provides 30 days of shadowing unless parties agree to a different time period. The Contractor with the State must review any Key Personnel replacements, and appropriate transition planning will be established. Any Unauthorized Removal may be considered by the State to be a material breach of the Contract, in respect of which the State may elect to exercise its termination and cancellation rights.

(e) The Contractor must notify the Contract Compliance Inspector at least 10 business days before redeploying non-Key Personnel, who are dedicated to primarily to the Project, to other projects. If the State does not object to the redeployment by its scheduled date, the Contractor may then redeploy the non-Key Personnel.

2.063 RE-ASSIGNMENT OF PERSONNEL AT THE STATE’S REQUEST

The State reserves the right to require the removal from the Project of Contractor personnel found, in the judgment of the State, to be unacceptable. The State’s request must be written with reasonable detail outlining the reasons for the removal request. Additionally, the State’s request must be based on legitimate, good faith reasons. Replacement personnel for the removed person must be fully qualified for the position. If the State exercises this right, and the Contractor cannot immediately replace the removed personnel, the State agrees to an equitable adjustment in schedule or other terms that may be affected by the State’s required removal. If any incident with removed personnel results in delay not reasonably anticipatable under the circumstances and which is attributable to the State, the applicable SLAs for the affected Service shall not be counted for a time as agreed to by the parties.

2.064 CONTRACTOR PERSONNEL LOCATION

All staff assigned by Contractor to work on the Contract shall perform their duties either primarily at Contractor’s offices and facilities or at State facilities. Without limiting the generality of the foregoing, Key Personnel shall, at a minimum, spend at least the amount of time on-site at State facilities as indicated in the Contract or any Statement of Work issued under it Subject to availability, selected Contractor personnel may be assigned office space to be shared with State personnel.

2.065 CONTRACTOR IDENTIFICATION

Contractor employees must be clearly identifiable while on State property by wearing a State-issued badge, as required. Contractor employees are required to clearly identify themselves and the company they work for whenever making contact with State personnel by telephone or other means.

2.066 COOPERATION WITH THIRD PARTIES

Contractor agrees to cause its personnel and the personnel of any SubContractors to cooperate with the State and its agents and other Contractors including the State’s Quality Assurance personnel. As reasonably requested by the State in writing, the Contractor shall provide to the State’s agents and other Contractors reasonable access to Contractor’s Project personnel, systems and facilities to the extent the access relates to activities specifically associated with this Contract and shall not interfere or jeopardize the safety or operation of the systems or facilities. The State acknowledges that Contractor’s time schedule for the Contract is very specific and agrees not to unnecessarily or unreasonably interfere with, delay or otherwise impeded Contractor’s performance under this Contract with the requests for access.

2.067 CONTRACT MANAGEMENT RESPONSIBILITIES

Contractor shall be responsible for all acts and omissions of its employees, as well as the acts and omissions of any other personnel furnished by Contractor to perform the Services. Contractor shall have overall responsibility for managing and successfully performing and completing the Services/Deliverables, subject to the overall direction and supervision of the State and with the participation and support of the State as


152

specified in this Contract. Contractor’s duties shall include monitoring and reporting the State’s performance of its participation and support responsibilities (as well as Contractor’s own responsibilities) and providing timely notice to the State in Contractor’s reasonable opinion if the State’s failure to perform its responsibilities in accordance with the Project Plan is likely to delay the timely achievement of any Contract tasks. The Contractor shall provide the Services/Deliverables directly or through its affiliates, subsidiaries, subContractors or resellers. Regardless of the entity providing the Service/Deliverable, the Contractor shall act as a single point of contact coordinating these entities to meet the State’s need for Services/Deliverables. Nothing in this Contract, however, shall be construed to authorize or require any party to violate any applicable law or regulation in its performance of this Contract.

2.068 CONTRACTOR RETURN OF STATE EQUIPMENT/RESOURCES

The Contractor shall return to the State any State-furnished equipment, facilities and other resources when no longer required for the Contract in the same condition as when provided by the State, reasonable wear and tear excepted.

2.070 Subcontracting by Contractor

2.071 CONTRACTOR FULL RESPONSIBILITY

Contractor shall have full responsibility for the successful performance and completion of all of the Services and Deliverables. The State shall consider Contractor to be the sole point of contact with regard to all contractual matters under this Contract, including payment of any and all charges for Services and Deliverables.

2.072 STATE CONSENT TO DELEGATION

Contractor shall not delegate any duties under this Contract to a SubContractor unless the Department of Technology, Management and Budget, Procurement has given written consent to such delegation. The State shall have the right of prior written approval of all SubContractors and to require Contractor to replace any SubContractors found, in the reasonable judgment of the State, to be unacceptable. The State’s request shall be written with reasonable detail outlining the reasons for the removal request. Additionally, the State’s request shall be based on legitimate, good faith reasons. Replacement SubContractor(s) for the removed SubContractor shall be fully qualified for the position. If the State exercises this right, and the Contractor cannot immediately replace the removed SubContractor, the State shall agree to an equitable adjustment in schedule or other terms that may be affected by the State’s required removal. If any such incident with a removed SubContractor results in delay not reasonable anticipatable under the circumstances and which is attributable to the State, the applicable SLA for the affected Work shall not be counted for a time agreed upon by the parties.

2.073 SUBCONTRACTOR BOUND TO CONTRACT

In any subcontracts entered into by Contractor for the performance of the Services, Contractor shall require the SubContractor, to the extent of the Services to be performed by the SubContractor, to be bound to Contractor by the terms of this Contract and to assume toward Contractor all of the obligations and responsibilities that Contractor, by this Contract, assumes toward the State. The State reserves the right to receive copies of and review all subcontracts, although Contractor may delete or mask any proprietary information, including pricing, contained in such contracts before providing them to the State. The management of any SubContractor shall be the responsibility of Contractor, and Contractor shall remain responsible for the performance of its SubContractors to the same extent as if Contractor had not subcontracted such performance. Contractor shall make all payments to SubContractors or suppliers of Contractor. Except as otherwise agreed in writing by the State and Contractor, the State shall not be obligated to direct payments for the Services other than to Contractor. The State’s written approval of any SubContractor engaged by Contractor to perform any obligation under this Contract shall not relieve Contractor of any obligations or performance required under this Contract. A list of the SubContractors, if any, approved by the State as of the execution of this Contract, together with a copy of the applicable subcontract is attached.


153

2.074 FLOW DOWN

Except where specifically approved in writing by the State on a case-by-case basis, Contractor shall flow down the obligations in Sections 2.031, 2.060, 2.100, 2.110, 2.120, 2.130, and 2.200 in all of its agreements with any SubContractors.

2.075 COMPETITIVE SELECTION

The Contractor shall select subContractors (including suppliers) on a competitive basis to the maximum practical extent consistent with the objectives and requirements of the Contract.

2.080 State Responsibilities

2.081 EQUIPMENT

The State shall provide only the equipment and resources identified in the Contract or any Statement of Work issued under it and other Contract Exhibits.

2.082 FACILITIES

The State must designate space as long as it is available and as provided in the Statement of Work, to house the Contractor’s personnel whom the parties agree will perform the Services/Deliverables at State facilities (collectively, the “State Facilities”). The Contractor shall have reasonable access to, and unless agreed otherwise by the parties in writing must observe and comply with all rules and regulations relating to each of the State Facilities (including hours of operation) used by the Contractor in the course of providing the Services. Contractor agrees that it shall not, without the prior written consent of the State, use any State Facilities or access any State information systems provided for the Contractor’s use, or to which the Contractor otherwise gains access in the course of performing the Services, for any purpose other than providing the Services to the State.

2.090 Security

2.091 BACKGROUND CHECKS

On a case-by-case basis, the State may investigate the Contractor's personnel before they may have access to State facilities and systems. The scope of the background check is at the discretion of the State and the results shall be used to determine Contractor personnel eligibility for working within State facilities and systems. The investigations shall include Michigan State Police Background checks (ICHAT) and may include the National Crime Information Center (NCIC) Finger Prints. Proposed Contractor personnel may be required to complete and submit an RI-8 Fingerprint Card for the NCIC Finger Print Check. Any request for background checks shall be initiated by the State and shall be reasonably related to the type of work requested.

2.100 Confidentiality

2.101 CONFIDENTIALITY

Contractor and the State each acknowledge that the other possesses and shall continue to possess confidential information that has been developed or received by it. As used in this Section, “Confidential Information” of Contractor must mean all non-public proprietary information of Contractor (other than Confidential Information of the State as defined below), which is marked confidential, restricted, proprietary, or with a similar designation. “Confidential Information” of the State must mean any information which is retained in confidence by the State (or otherwise required to be held in confidence by the State under applicable federal, state and local laws and regulations) or which, in the case of tangible materials provided to Contractor by the State under its performance under this Contract, is marked as confidential, proprietary or with a similar designation by the State. “Confidential Information” excludes any information (including this Contract) that is publicly available under the Michigan FOIA.


154

2.102 PROTECTION AND DESTRUCTION OF CONFIDENTIAL INFORMATION

The State and Contractor shall each use at least the same degree of care to prevent disclosing to third parties the Confidential Information of the other as it employs to avoid unauthorized disclosure, publication or dissemination of its own confidential information of like character, but in no event less than reasonable care. Neither Contractor nor the State shall (i) make any use of the Confidential Information of the other except as contemplated by this Contract, (ii) acquire any right in or assert any lien against the Confidential Information of the other, or (iii) if requested to do so, refuse for any reason to promptly return the other party's Confidential Information to the other party. Each party shall limit disclosure of the other party’s Confidential Information to employees and SubContractors who must have access to fulfill the purposes of this Contract. Disclosure to, and use by, a SubContractor is permissible where (A) use of a SubContractor is authorized under this Contract, (B) the disclosure is necessary or otherwise naturally occurs in connection with work that is within the SubContractor's scope of responsibility, and (C) Contractor obligates the SubContractor in a written Contract to maintain the State’s Confidential Information in confidence. At the State's request, any employee of Contractor and of any SubContractor having access or continued access to the State’s Confidential Information may be required to execute an acknowledgment that the employee has been advised of Contractor’s and the SubContractor’s obligations under this Section and of the employee’s obligation to Contractor or SubContractor, as the case may be, to protect the Confidential Information from unauthorized use or disclosure. Promptly upon termination or cancellation of the Contract for any reason, Contractor must certify to the State that Contractor has destroyed all State Confidential Information.

2.103 PCI DATA SECURITY STANDARD

(a) Contractors that process, transmit or store credit/debit cardholder data, must adhere to the Payment Card Industry (PCI) Data Security Standards. The Contractor is responsible for the security of cardholder data in its possession. The data may only be used to assist the State or for other uses specifically authorized by law. (b) The Contractor must notify the CCI (within 72 hours of discovery) of any breaches in security where cardholder data has been compromised. In that event, the Contractor must provide full cooperation to the Visa, MasterCard, Discover and state Acquirer representative(s), and/or a PCI approved third party to conduct a thorough security review. The Contractor must make the forensic report available within two weeks of completion. The review must validate compliance with the current PCI Data Security Standards for protecting cardholder data. (c) The Contractor must properly dispose of cardholder data, in compliance with DTMB policy, when it is no longer needed. The Contractor must continue to treat cardholder data as confidential upon contract termination. (d) The Contractor must provide the CCI with an annual Attestation of Compliance (AOC) or a Report on Compliance (ROC) showing the Contractor is in compliance with the PCI Data Security Standards. The Contractor must notify the CCI of all failures to comply with the PCI Data Security Standard.

2.104 EXCLUSIONS

Notwithstanding the foregoing, the provisions in this Section shall not apply to any particular information which the State or Contractor can demonstrate (i) was, at the time of disclosure to it, in the public domain; (ii) after disclosure to it, is published or otherwise becomes part of the public domain through no fault of the receiving party; (iii) was in the possession of the receiving party at the time of disclosure to it without an obligation of confidentiality; (iv) was received after disclosure to it from a third party who had a lawful right to disclose the information to it without any obligation to restrict its further disclosure; or (v) was independently developed by the receiving party without reference to Confidential Information of the furnishing party. Further, the provisions of this Section shall not apply to any particular Confidential Information to the extent the receiving party is required by law to disclose the Confidential Information, provided that the receiving party (i) promptly provides


155

the furnishing party with notice of the legal request, and (ii) assists the furnishing party in resisting or limiting the scope of the disclosure as reasonably requested by the furnishing party.

2.105 NO IMPLIED RIGHTS

Nothing contained in this Section must be construed as obligating a party to disclose any particular Confidential Information to the other party, or as granting to or conferring on a party, expressly or impliedly, any right or license to the Confidential Information of the other party.

2.106 SECURITY BREACH NOTIFICATION

If the Contractor breaches this Section, the Contractor must (i) promptly cure any deficiencies and (ii) comply with any applicable federal and state laws and regulations pertaining to unauthorized disclosures. Contractor and the State shall cooperate to mitigate, to the extent practicable, the effects of any breach, intrusion, or unauthorized use or disclosure. Contractor must report to the State in writing any use or disclosure of Confidential Information, whether suspected or actual, other than as provided for by the Contract within 72 hours of becoming aware of the use or disclosure or the shorter time period as is reasonable under the circumstances.

2.107 RESPECTIVE OBLIGATIONS

The parties’ respective obligations under this Section must survive the termination or expiration of this Contract for any reason.

2.110 Records and Inspections

2.111 INSPECTION OF WORK PERFORMED

The State's authorized representatives, at reasonable times and with 10 days prior notice, have the right to enter the Contractor's premises or any other places where work is being performed in relation to this Contract. The representatives may inspect, monitor, or evaluate the work being performed, to the extent the access will not reasonably interfere with or jeopardize the safety or operation of Contractor's systems or facilities. The Contractor must provide reasonable assistance for the State's representatives during inspections.

2.112 RETENTION OF RECORDS

(a) The Contractor must retain all financial and accounting records related to this Contract for a period of 7 years after the Contractor performs any work under this Contract (Audit Period). (b) If an audit, litigation, or other action involving the Contractor's records is initiated before the end of the Audit Period, the Contractor must retain the records until all issues arising out of the audit, litigation, or other action are resolved or until the end of the Audit Period, whichever is later.

2.113 EXAMINATION OF RECORDS

(a) The State, upon 10 days notice to the Contractor, may examine and copy any of the Contractor's records that relate to this Contract any time during the Audit Period. The State does not have the right to review any information deemed confidential by the Contractor if access would require the information to become publicly available. This requirement also applies to the records of any parent, affiliate, or subsidiary organization of the Contractor, or any SubContractor that performs services in connection with this Contract (b) In addition to the rights conferred upon the State in paragraph (a) of this section and in accordance with MCL 18.1470, DTMB or its designee may audit the Contractor to verify compliance with the Contract. The financial and accounting records associated with the Contract shall be made available to DTMB or its designee and the auditor general, upon request, during the term of the Contract and any extension of the Contract and for 3 years after the later of the expiration date or final payment under the Contract.


156

2.114 AUDIT RESOLUTION

If necessary, the Contractor and the State will meet to review any audit report promptly after its issuance. The Contractor must respond to each report in writing within 30 days after receiving the report, unless the report specifies a shorter response time. The Contractor and the State must develop, agree upon, and monitor an action plan to promptly address and resolve any deficiencies, concerns, or recommendations in the report.

2.115 ERRORS

(a) If an audit reveals any financial errors in the records provided to the State, the amount in error must be reflected as a credit or debit on the next invoice and subsequent invoices until the amount is paid or refunded in full. However, a credit or debit may not be carried forward for more than four invoices or beyond the termination of the Contract. If a balance remains after four invoices, the remaining amount will be due as a payment or refund within 45 days of the last invoice on which the balance appeared or upon termination of the Contract, whichever is earlier.

(b) In addition to other available remedies, if the difference between the State's actual payment and the correct invoice amount, as determined by an audit, is greater than 10%, the Contractor must pay all reasonable audit costs.

2.120 Warranties

2.121 WARRANTIES AND REPRESENTATIONS

The Contractor represents and warrants: (a) It is capable in all respects of fulfilling and must fulfill all of its obligations under this Contract. The

performance of all obligations under this Contract must be provided in a timely, professional, and workman-like manner and must meet the performance and operational standards required under this Contract.

(b) The Contract Appendices, Attachments and Exhibits identify the equipment and software and services necessary for the Deliverable(s) to perform and Services to operate in compliance with the Contract’s requirements and other standards of performance.

(c) It is the lawful owner or licensee of any Deliverable licensed or sold to the State by Contractor or developed by Contractor under this Contract, and Contractor has all of the rights necessary to convey to the State the ownership rights or licensed use, as applicable, of any and all Deliverables. None of the Deliverables provided by Contractor to the State under neither this Contract, nor their use by the State shall infringe the patent, copyright, trade secret, or other proprietary rights of any third party.

(d) If, under this Contract, Contractor procures any equipment, software or other Deliverable for the State (including equipment, software and other Deliverables manufactured, re-marketed or otherwise sold by Contractor under Contractor’s name), then in addition to Contractor’s other responsibilities with respect to the items in this Contract, Contractor must assign or otherwise transfer to the State or its designees, or afford the State the benefits of, any manufacturer's warranty for the Deliverable.

(e) The contract signatory has the power and authority, including any necessary corporate authorizations, necessary to enter into this Contract, on behalf of Contractor.

(f) It is qualified and registered to transact business in all locations where required. (g) Neither the Contractor nor any Affiliates, nor any employee of either, has, must have, or must acquire, any

contractual, financial, business, or other interest, direct or indirect, that would conflict in any manner or degree with Contractor’s performance of its duties and responsibilities to the State under this Contract or otherwise create an appearance of impropriety with respect to the award or performance of this Agreement. Contractor must notify the State about the nature of the conflict or appearance of impropriety within two days of learning about it.

(h) Neither Contractor nor any Affiliates, nor any employee of either has accepted or must accept anything of value based on an understanding that the actions of the Contractor or Affiliates or employee on behalf of the State would be influenced. Contractor must not attempt to influence any State employee by the direct or indirect offer of anything of value.


157

(i) Neither Contractor nor any Affiliates, nor any employee of either has paid or agreed to pay any person, other than bona fide employees and consultants working solely for Contractor or the Affiliate, any fee, commission, percentage, brokerage fee, gift, or any other consideration, contingent upon or resulting from the award or making of this Contract.

(j) The prices proposed by Contractor were arrived at independently, without consultation, communication, or agreement with any other Bidder for the purpose of restricting competition; the prices quoted were not knowingly disclosed by Contractor to any other Bidder; and no attempt was made by Contractor to induce any other person to submit or not submit a proposal for the purpose of restricting competition.

(k) All financial statements, reports, and other information furnished by Contractor to the State as part of its response to the RFP or otherwise in connection with the award of this Contract fairly and accurately represent the business, properties, financial condition, and results of operations of Contractor as of the respective dates, or for the respective periods, covered by the financial statements, reports, other information. Since the respective dates or periods covered by the financial statements, reports, or other information, there have been no material adverse changes in the business, properties, financial condition, or results of operations of Contractor.

(l) All written information furnished to the State by or for the Contractor in connection with this Contract, including its bid, is true, accurate, and complete, and contains no untrue statement of material fact or omits any material fact necessary to make the information not misleading.

(m) It is not in material default or breach of any other contract or agreement that it may have with the State or any of its departments, commissions, boards, or agencies. Contractor further represents and warrants that it has not been a party to any contract with the State or any of its departments that was terminated by the State or the department within the previous five years for the reason that Contractor failed to perform or otherwise breached an obligation of the contract.

(n) If any of the certifications, representations, or disclosures made in the Contractor’s original bid response change after contract award, the Contractor is required to report those changes immediately to the Department of Technology, Management and Budget, Procurement.

2.122 RESERVED

2.123 RESERVED

2.124 RESERVED

2.125 RESERVED

2.126 RESERVED

2.127 RESERVED

2.128 CONSEQUENCES FOR BREACH

In addition to any remedies available in law, if the Contractor breaches any of the warranties contained in this section, the breach may be considered as a default in the performance of a material obligation of this Contract.

2.130 Insurance

2.13.1 LIABILITY INSURANCE

For the purpose of this Section, "State" includes its departments, divisions, agencies, offices, commissions, officers, employees, and agents.

(a) The Contractor must provide proof that it has obtained the minimum levels of insurance coverage indicated or required by law, whichever is greater. The insurance must protect the State from claims that may arise out of, or result from, or are alleged to arise out of, or result from, the Contractor's or a SubContractor's performance, including any person directly or indirectly employed by the Contractor or a SubContractor, or any person for whose acts the Contractor or a SubContractor may be liable.

(b) The Contractor waives all rights against the State for the recovery of damages that are covered by the insurance policies the Contractor is required to maintain under this Section. The Contractor's failure to obtain and maintain the required insurance will not limit this waiver.


158

(c) All insurance coverage provided relative to this Contract is primary and non-contributing to any comparable liability insurance (including self-insurance) carried by the State.

(d) The State, in its sole discretion, may approve the use of a fully-funded self-insurance program in place of any specified insurance identified in this Section.

(e) Unless the State approves otherwise, any insurer must have an A.M. Best rating of "A" or better and a financial size of VII or better, or if those ratings are not available, a comparable rating from an insurance rating agency approved by the State. All policies of insurance must be issued by companies that have been approved to do business in the State.

(f) Where specific coverage limits are listed in this Section, they represent the minimum acceptable limits. If the Contractor's policy contains higher limits, the State is entitled to coverage to the extent of the higher limits.

(g) The Contractor must maintain all required insurance coverage throughout the term of this Contract and any extensions. However, in the case of claims-made Commercial General Liability policies, the Contractor must secure tail coverage for at least three (3) years following the termination of this Contract.

(h) The Contractor must provide, within five (5) business days, written notice to the Director of DTMB-Procurement if any policy required under this section is cancelled. The notice must include the applicable Contract or Purchase Order number.

(i) The minimum limits of coverage specified are not intended, and may not be construed, to limit any liability or indemnity of the Contractor to any indemnified party or other persons.

(j) The Contractor is responsible for the payment of all deductibles. (k) If the Contractor fails to pay any premium for a required insurance policy, or if any insurer cancels

or significantly reduces any required insurance without the State's approval, the State may, after giving the Contractor at least 30 days’ notice, pay the premium or procure similar insurance coverage from another company or companies. The State may deduct any part of the cost from any payment due the Contractor, or require the Contractor to pay that cost upon demand.

(l) In the event the State approves the representation of the State by the insurer's attorney, the attorney may be required to be designated as a Special Assistant Attorney General by the Michigan Attorney General.

(m) The Contractor is required to pay for and provide the type and amount of insurance checked below:

(i) Commercial General Liability Minimal Limits:

$2,000,000 General Aggregate Limit other than Products/Completed Operations; $2,000,000 Products/Completed Operations Aggregate Limit; $1,000,000 Personal & Advertising Injury Limit; and $1,000,000 Each Occurrence Limit.

Deductable maximum: $50,000 Each Occurrence

Additional Requirements: The Contractor must list the State of Michigan, its departments, divisions, agencies, offices, commissions, officers, employees, and agents as additional insureds on the Commercial General Liability certificate. The Contractor also agrees to provide evidence that the insurance policy contains a waiver of subrogation by the insurance company.

(iii) Motor Vehicle Minimal Limits:

If a motor vehicle is used in relation to the Contractor's performance, the Contractor must have vehicle liability insurance on the motor vehicle for bodily injury and property damage as required by law.

(v) Workers' Compensation


159

Minimal Limits: The Contractor must provide Workers' Compensation coverage according to applicable laws governing work activities in the state of the Contractor's domicile. If the applicable coverage is provided by a self-insurer, the Contractor must provide proof of an approved self-insured authority by the jurisdiction of domicile. For employees working outside of the state of the Contractor's domicile, the Contractor must provide certificates of insurance proving mandated coverage levels for the jurisdictions where the employees' activities occur.

Additional Requirements: The Contractor must provide the applicable certificates of insurance and a list of states where the coverage is applicable. Contractor must provide proof that the Workers' Compensation insurance policies contain a waiver of subrogation by the insurance company, except where such a provision is prohibited or limited by the laws of the jurisdiction in which the work is to be performed.

(vi) Employers Liability

Minimal Limits: $100,000 Each Incident; $100,000 Each Employee by Disease $500,000 Aggregate Disease

Additional Requirements: The Contractor must list the State of Michigan, its departments, divisions, agencies, offices, commissions, officers, employees, and agents as additional insureds on the certificate.

(ix) Cyber Liability Minimal Limits: $1,000,000 Each Occurrence $1,000,000 Annual Aggregate Additional Requirements: Insurance should cover (a)unauthorized acquisition, access, use, physical taking, identity theft, mysterious disappearance, release, distribution or disclosures of personal and corporate information; (b) Transmitting or receiving malicious code via the insured's computer system; (c) Denial of service attacks or the inability to access websites or computer systems. The Contractor must list the State of Michigan, its departments, divisions, agencies, offices, commissions, officers, employees, and agents as additional insureds on the certificate.

2.13.2 SUBCONTRACTOR INSURANCE COVERAGE

Except where the State has approved a subcontract with other insurance provisions, the Contractor must require any SubContractor to purchase and maintain the insurance coverage required in Section 2.13.1, Liability Insurance. Alternatively, the Contractor may include a SubContractor under the Contractor's insurance on the coverage required in that Section. The failure of a SubContractor to comply with insurance requirements does not limit the Contractor's liability or responsibility.

2.13.3 CERTIFICATES OF INSURANCE

Before the Contract is signed, and not less than 20 days before the insurance expiration date every year thereafter, the Contractor must provide evidence that the State of Michigan, its departments, divisions, agencies, offices, commissions, officers, employees, and agents are listed as additional insureds as required. The Contractor must provide DTMB-Procurement with all applicable certificates of insurance verifying


160

insurance coverage or providing, if approved, satisfactory evidence of self-insurance as required in Section 2.13.1, Liability Insurance. Each certificate must be on the standard "Accord" form or equivalent and MUST IDENTIFY THE APPLICABLE CONTRACT OR PURCHASE ORDER NUMBER.

2.140 Indemnification

2.141 GENERAL INDEMNIFICATION

To the extent permitted by law, the Contractor must indemnify, defend and hold harmless the State from liability, including all claims and losses, and all related costs and expenses (including reasonable attorneys’ fees and costs of investigation, litigation, settlement, judgments, interest and penalties), accruing or resulting to any person, firm or corporation that may be injured or damaged by the Contractor in the performance of this Contract and that are attributable to the negligence or tortious acts of the Contractor or any of its subContractors, or by anyone else for whose acts any of them may be liable.

2.142 CODE INDEMNIFICATION

To the extent permitted by law, the Contractor shall indemnify, defend and hold harmless the State from any claim, loss, or expense arising from Contractor’s breach of the No Surreptitious Code Warranty.

2.143 EMPLOYEE INDEMNIFICATION

In any claims against the State of Michigan, its departments, divisions, agencies, sections, commissions, officers, employees and agents, by any employee of the Contractor or any of its subContractors, the indemnification obligation under the Contract must not be limited in any way by the amount or type of damages, compensation or benefits payable by or for the Contractor or any of its subContractors under worker’s disability compensation acts, disability benefit acts or other employee benefit acts. This indemnification clause is intended to be comprehensive. Any overlap in provisions, or the fact that greater specificity is provided as to some categories of risk, is not intended to limit the scope of indemnification under any other provisions.

2.144 PATENT/COPYRIGHT INFRINGEMENT INDEMNIFICATION

To the extent permitted by law, the Contractor must indemnify, defend and hold harmless the State from and against all losses, liabilities, damages (including taxes), and all related costs and expenses (including reasonable attorneys’ fees and costs of investigation, litigation, settlement, judgments, interest and penalties) incurred in connection with any action or proceeding threatened or brought against the State to the extent that the action or proceeding is based on a claim that any piece of equipment, software, commodity or service supplied by the Contractor or its subContractors, or the operation of the equipment, software, commodity or service, or the use or reproduction of any documentation provided with the equipment, software, commodity or service infringes any United States patent, copyright, trademark or trade secret of any person or entity, which is enforceable under the laws of the United States.

In addition, should the equipment, software, commodity, or service, or its operation, become or in the State’s or Contractor’s opinion be likely to become the subject of a claim of infringement, the Contractor must at the Contractor’s sole expense (i) procure for the State the right to continue using the equipment, software, commodity or service or, if the option is not reasonably available to the Contractor, (ii) replace or modify to the State’s satisfaction the same with equipment, software, commodity or service of equivalent function and performance so that it becomes non-infringing, or, if the option is not reasonably available to Contractor, (iii) accept its return by the State with appropriate credits to the State against the Contractor’s charges and reimburse the State for any losses or costs incurred as a consequence of the State ceasing its use and returning it.

Notwithstanding the foregoing, the Contractor has no obligation to indemnify or defend the State for, or to pay any costs, damages or attorneys’ fees related to, any claim based upon (i) equipment developed based on written specifications of the State; (ii) use of the equipment in a configuration other than implemented or approved in writing by the Contractor, including, but not limited to, any modification of the equipment by the


161

State; or (iii) the combination, operation, or use of the equipment with equipment or software not supplied by the Contractor under this Contract.

2.145 CONTINUATION OF INDEMNIFICATION OBLIGATIONS

The Contractor’s duty to indemnify under this Section continues in full force and effect, notwithstanding the expiration or early cancellation of the Contract, with respect to any claims based on facts or conditions that occurred before expiration or cancellation.

2.146 INDEMNIFICATION PROCEDURES

The procedures set forth below must apply to all indemnity obligations under this Contract. (a) After the State receives notice of the action or proceeding involving a claim for which it shall seek

indemnification, the State must promptly notify Contractor of the claim in writing and take or assist Contractor in taking, as the case may be, any reasonable action to avoid the imposition of a default judgment against Contractor. No failure to notify the Contractor relieves the Contractor of its indemnification obligations except to the extent that the Contractor can prove damages attributable to the failure. Within 10 days following receipt of written notice from the State relating to any claim, the Contractor must notify the State in writing whether Contractor agrees to assume control of the defense and settlement of that claim (a “Notice of Election”). After notifying Contractor of a claim and before the State receiving Contractor’s Notice of Election, the State is entitled to defend against the claim, at the Contractor’s expense, and the Contractor will be responsible for any reasonable costs incurred by the State in defending against the claim during that period.

(b) If Contractor delivers a Notice of Election relating to any claim: (i) the State is entitled to participate in the defense of the claim and to employ counsel at its own expense to assist in the handling of the claim and to monitor and advise the State about the status and progress of the defense; (ii) the Contractor must, at the request of the State, demonstrate to the reasonable satisfaction of the State, the Contractor’s financial ability to carry out its defense and indemnity obligations under this Contract; (iii) the Contractor must periodically advise the State about the status and progress of the defense and must obtain the prior written approval of the State before entering into any settlement of the claim or ceasing to defend against the claim and (iv) to the extent that any principles of Michigan governmental or public law may be involved or challenged, the State has the right, at its own expense, to control the defense of that portion of the claim involving the principles of Michigan governmental or public law. But the State may retain control of the defense and settlement of a claim by notifying the Contractor in writing within 10 days after the State’s receipt of Contractor’s information requested by the State under clause (ii) of this paragraph if the State determines that the Contractor has failed to demonstrate to the reasonable satisfaction of the State the Contractor’s financial ability to carry out its defense and indemnity obligations under this Section. Any litigation activity on behalf of the State, or any of its subdivisions under this Section, must be coordinated with the Department of Attorney General. In the event the insurer’s attorney represents the State under this Section, the insurer’s attorney may be required to be designated as a Special Assistant Attorney General by the Attorney General of the State of Michigan.

(c) If Contractor does not deliver a Notice of Election relating to any claim of which it is notified by the State as provided above, the State may defend the claim in the manner as it may deem appropriate, at the cost and expense of Contractor. If it is determined that the claim was one against which Contractor was required to indemnify the State, upon request of the State, Contractor must promptly reimburse the State for all the reasonable costs and expenses.

2.150 Termination/Cancellation

2.151 NOTICE AND RIGHT TO CURE

If the Contractor breaches the contract, and the State in its sole discretion determines that the breach is curable, then the State shall provide the Contractor with written notice of the breach and a time period (not less than 30 days) to cure the Breach. The notice of breach and opportunity to cure is inapplicable for successive or repeated breaches or if the State determines in its sole discretion that the breach poses a serious and


162

imminent threat to the health or safety of any person or the imminent loss, damage, or destruction of any real or tangible personal property.

2.152 TERMINATION FOR CAUSE

(a) The State may terminate this contract, for cause, by notifying the Contractor in writing, if the Contractor (i) breaches any of its material duties or obligations under this Contract (including a Chronic Failure to meet any particular SLA), or (ii) fails to cure a breach within the time period specified in the written notice of breach provided by the State

(b) If this Contract is terminated for cause, the Contractor must pay all costs incurred by the State in terminating this Contract, including but not limited to, State administrative costs, reasonable attorneys’ fees and court costs, and any reasonable additional costs the State may incur to procure the Services/Deliverables required by this Contract from other sources. Re-procurement costs are not consequential, indirect or incidental damages, and cannot be excluded by any other terms otherwise included in this Contract, provided the costs are not in excess of 50% more than the prices for the Service/Deliverables provided under this Contract.

(c) If the State chooses to partially terminate this Contract for cause, charges payable under this Contract shall be equitably adjusted to reflect those Services/Deliverables that are terminated and the State must pay for all Services/Deliverables for which Final Acceptance has been granted provided up to the termination date. Services and related provisions of this Contract that are terminated for cause must cease on the effective date of the termination.

(d) If the State terminates this Contract for cause under this Section, and it is determined, for any reason, that Contractor was not in breach of contract under the provisions of this section, that termination for cause must be deemed to have been a termination for convenience, effective as of the same date, and the rights and obligations of the parties must be limited to that otherwise provided in this Contract for a termination for convenience.

2.153 TERMINATION FOR CONVENIENCE

The State may terminate this Contract for its convenience, in whole or part, if the State determines that a termination is in the State’s best interest. Reasons for the termination must be left to the sole discretion of the State and may include, but not necessarily be limited to (a) the State no longer needs the Services or products specified in the Contract, (b) relocation of office, program changes, changes in laws, rules, or regulations make implementation of the Services no longer practical or feasible, (c) unacceptable prices for Additional Services or New Work requested by the State, or (d) falsification or misrepresentation, by inclusion or non-inclusion, of information material to a response to any RFP issued by the State. The State may terminate this Contract for its convenience, in whole or in part, by giving Contractor written notice at least 30 days before the date of termination. If the State chooses to terminate this Contract in part, the charges payable under this Contract must be equitably adjusted to reflect those Services/Deliverables that are terminated. Services and related provisions of this Contract that are terminated for convenience must cease on the effective date of the termination.

2.154 TERMINATION FOR NON-APPROPRIATION

(a) Contractor acknowledges that, if this Contract extends for several fiscal years, continuation of this Contract is subject to appropriation or availability of funds for this Contract. If funds to enable the State to effect continued payment under this Contract are not appropriated or otherwise made available, the State must terminate this Contract and all affected Statements of Work, in whole or in part, at the end of the last period for which funds have been appropriated or otherwise made available by giving written notice of termination to Contractor. The State must give Contractor at least 30 days advance written notice of termination for non-appropriation or unavailability (or the time as is available if the State receives notice of the final decision less than 30 days before the funding cutoff).

(b) If funding for the Contract is reduced by law, or funds to pay Contractor for the agreed-to level of the Services or production of Deliverables to be provided by Contractor are not appropriated or otherwise unavailable, the State may, upon 30 days written notice to Contractor, reduce the level of the Services or change the production of Deliverables in the manner and for the periods of time as the State may elect.


163

The charges payable under this Contract shall be equitably adjusted to reflect any equipment, services or commodities not provided by reason of the reduction.

(c) If the State terminates this Contract, eliminates certain Deliverables, or reduces the level of Services to be provided by Contractor under this Section, the State must pay Contractor for all Work-in-Process performed through the effective date of the termination or reduction in level, as the case may be and as determined by the State, to the extent funds are available. This Section shall not preclude Contractor from reducing or stopping Services/Deliverables or raising against the State in a court of competent jurisdiction, any claim for a shortfall in payment for Services performed or Deliverables finally accepted before the effective date of termination.

2.155 TERMINATION FOR CRIMINAL CONVICTION

The State may terminate this Contract immediately and without further liability or penalty in the event Contractor, an officer of Contractor, or an owner of a 25% or greater share of Contractor is convicted of a criminal offense related to a State, public or private Contract or subcontract.

2.156 TERMINATION FOR APPROVALS RESCINDED

The State may terminate this Contract if any final administrative or judicial decision or adjudication disapproves a previously approved request for purchase of personal services under Constitution 1963, Article 11, § 5, and Civil Service Rule 7-1. In that case, the State shall pay the Contractor for only the work completed to that point under the Contract. Termination may be in whole or in part and may be immediate as of the date of the written notice to Contractor or may be effective as of the date stated in the written notice.

2.157 RIGHTS AND OBLIGATIONS UPON TERMINATION

(a) If the State terminates this Contract for any reason, the Contractor must (a) stop all work as specified in the notice of termination, (b) take any action that may be necessary, or that the State may direct, for preservation and protection of Deliverables or other property derived or resulting from this Contract that may be in Contractor’s possession, (c) return all materials and property provided directly or indirectly to Contractor by any entity, agent or employee of the State, (d) transfer title in, and deliver to, the State, unless otherwise directed, all Deliverables intended to be transferred to the State at the termination of the Contract and which are resulting from the Contract (which must be provided to the State on an “As-Is” basis except to the extent the amounts paid by the State in respect of the items included compensation to Contractor for the provision of warranty services in respect of the materials), and (e) take any action to mitigate and limit any potential damages, or requests for Contractor adjustment or termination settlement costs, to the maximum practical extent, including terminating or limiting as otherwise applicable those subcontracts and outstanding orders for material and supplies resulting from the terminated Contract.

(b) If the State terminates this Contract before its expiration for its own convenience, the State must pay Contractor for all charges due for Services provided before the date of termination and, if applicable, as a separate item of payment under this Contract, for Work In Process, on a percentage of completion basis at the level of completion determined by the State. All completed or partially completed Deliverables prepared by Contractor under this Contract, at the option of the State, becomes the State’s property, and Contractor is entitled to receive equitable fair compensation for the Deliverables. Regardless of the basis for the termination, the State is not obligated to pay, or otherwise compensate, Contractor for any lost expected future profits, costs or expenses incurred with respect to Services not actually performed for the State.

(c) Upon a good faith termination, the State may assume, at its option, any subcontracts and agreements for services and deliverables provided under this Contract, and may further pursue completion of the Services/Deliverables under this Contract by replacement contract or otherwise as the State may in its sole judgment deem expedient.

2.158 RESERVATION OF RIGHTS

Any termination of this Contract or any Statement of Work issued under it by a party must be with full reservation of, and without prejudice to, any rights or remedies otherwise available to the party with respect to any claims arising before or as a result of the termination.


164

2.160 Termination by Contractor

2.161 TERMINATION BY CONTRACTOR

If the State breaches the Contract, and the Contractor in its sole discretion determines that the breach is curable, then the Contractor will provide the State with written notice of the breach and a time period (not less than 30 days) to cure the breach. The Notice of Breach and opportunity to cure is inapplicable for successive and repeated breaches. The Contractor may terminate this Contract if the State (i) materially breaches its obligation to pay the Contractor undisputed amounts due and owing under this Contract, (ii) breaches its other obligations under this Contract to an extent that makes it impossible or commercially impractical for the Contractor to perform the Services, or (iii) does not cure the breach within the time period specified in a written notice of breach. But the Contractor must discharge its obligations under Section 2.160 before it terminates the Contract.

2.170 Transition Responsibilities

2.171 CONTRACTOR TRANSITION RESPONSIBILITIES

If the State terminates this contract, for convenience or cause, or if the Contract is otherwise dissolved, voided, rescinded, nullified, expires or rendered unenforceable, the Contractor shall comply with direction provided by the State to assist in the orderly transition of equipment, services, software, leases, etc. to the State or a third party designated by the State. If this Contract expires or terminates, the Contractor agrees to make all reasonable efforts to effect an orderly transition of services within a reasonable period of time that in no event will exceed ninety days. These efforts must include, but are not limited to, those listed in Section 2.150.

2.172 CONTRACTOR PERSONNEL TRANSITION

The Contractor shall work with the State, or a specified third party, to develop a transition plan setting forth the specific tasks and schedule to be accomplished by the parties, to effect an orderly transition. The Contractor must allow as many personnel as practicable to remain on the job to help the State, or a specified third party, maintain the continuity and consistency of the services required by this Contract. In addition, during or following the transition period, in the event the State requires the Services of the Contractor’s subContractors or vendors, as necessary to meet its needs, Contractor agrees to reasonably, and with good-faith, work with the State to use the Services of Contractor’s subContractors or vendors. Contractor will notify all of Contractor’s subContractors of procedures to be followed during transition.

2.173 CONTRACTOR INFORMATION TRANSITION

The Contractor shall provide reasonable detailed specifications for all Services/Deliverables needed by the State, or specified third party, to properly provide the Services/Deliverables required under this Contract. The Contractor will provide the State with asset management data generated from the inception of this Contract through the date on which this Contractor is terminated in a comma-delineated format unless otherwise requested by the State. The Contractor will deliver to the State any remaining owed reports and documentation still in Contractor’s possession subject to appropriate payment by the State.

2.174 CONTRACTOR SOFTWARE TRANSITION

The Contractor shall reasonably assist the State in the acquisition of any Contractor software required to perform the Services/use the Deliverables under this Contract. This must include any documentation being used by the Contractor to perform the Services under this Contract. If the State transfers any software licenses to the Contractor, those licenses must, upon expiration of the Contract, transfer back to the State at their current revision level. Upon notification by the State, Contractor may be required to freeze all non-critical changes to Deliverables/Services.


165

2.175 TRANSITION PAYMENTS

If the transition results from a termination for any reason, the termination provisions of this Contract must govern reimbursement. If the transition results from expiration, the Contractor will be reimbursed for all reasonable transition costs (i.e. costs incurred within the agreed period after contract expiration that result from transition operations) at the rates agreed upon by the State. The Contractor will prepare an accurate accounting from which the State and Contractor may reconcile all outstanding accounts.

2.176 STATE TRANSITION RESPONSIBILITIES

In the event that this Contract is terminated, dissolved, voided, rescinded, nullified, or otherwise rendered unenforceable, the State agrees to reconcile all accounts between the State and the Contractor, complete any pending post-project reviews and perform any others obligations upon which the State and the Contractor agree. (a) Reconciling all accounts between the State and the Contractor; (b) Completing any pending post-project reviews.

2.180 Stop Work

2.181 STOP WORK ORDERS

The State may, at any time, by written Stop Work Order to Contractor, require that Contractor stop all, or any part, of the work called for by the Contract for a period of up to 90 calendar days after the Stop Work Order is delivered to Contractor, and for any further period to which the parties may agree. The Stop Work Order must be identified as a Stop Work Order and must indicate that it is issued under this Section. Upon receipt of the stop work order, Contractor must immediately comply with its terms and take all reasonable steps to minimize incurring costs allocable to the work covered by the Stop Work Order during the period of work stoppage. Within the period of the stop work order, the State must either: (a) cancel the stop work order; or (b) terminate the work covered by the Stop Work Order as provided in Section 2.182.

2.182 CANCELLATION OR EXPIRATION OF STOP WORK ORDER

The Contractor shall resume work if the State cancels a Stop Work Order or if it expires. The parties shall agree upon an equitable adjustment in the delivery schedule, the Contract price, or both, and the Contract shall be modified, in writing, accordingly, if: (a) the Stop Work Order results in an increase in the time required for, or in Contractor’s costs properly allocable to, the performance of any part of the Contract; and (b) Contractor asserts its right to an equitable adjustment within 30 calendar days after the end of the period of work stoppage; provided that, if the State decides the facts justify the action, the State may receive and act upon a Contractor proposal submitted at any time before final payment under the Contract. Any adjustment will conform to the requirements of Section 2.024.

2.183 ALLOWANCE OF CONTRACTOR COSTS

If the Stop Work Order is not canceled and the work covered by the Stop Work Order is terminated for reasons other than material breach, the termination shall be deemed to be a termination for convenience under Section 2.153, and the State shall pay reasonable costs resulting from the Stop Work Order in arriving at the termination settlement. For the avoidance of doubt, the State shall not be liable to Contractor for loss of profits because of a Stop Work Order issued under this Section.

2.190 Dispute Resolution

2.191 IN GENERAL

Any claim, counterclaim, or dispute between the State and Contractor arising out of or relating to the Contract or any Statement of Work issued under it must be resolved as follows. For all Contractor claims seeking an increase in the amounts payable to Contractor under the Contract, or the time for Contractor’s performance, Contractor must submit a letter, together with all data supporting the claims, executed by the Contractor’s SPOC or the Contractor’s SPOC designee certifying that (a) the claim is made in good faith, (b) the amount


166

claimed accurately reflects the adjustments in the amounts payable to Contractor or the time for Contractor’s performance for which Contractor believes the State is liable and covers all costs of every type to which Contractor is entitled from the occurrence of the claimed event, and (c) the claim and the supporting data are current and complete to Contractor’s best knowledge and belief.

2.192 INFORMAL DISPUTE RESOLUTION

(a) All disputes between the parties shall be resolved under the Contract Management procedures in this Contract. If the parties are unable to resolve any dispute after compliance with the processes, the parties must meet with the Director of Procurement, DTMB, or designee, to resolve the dispute without the need for formal legal proceedings, as follows: (1) The representatives of Contractor and the State must meet as often as the parties reasonably deem necessary to gather and furnish to each other all information with respect to the matter at issue which the parties believe to be appropriate and germane in connection with its resolution. The representatives shall discuss the problem and negotiate in good faith in an effort to resolve the dispute without the necessity of any formal proceeding. (2) During the course of negotiations, all reasonable requests made by one party to another for non-privileged information reasonably related to the Contract shall be honored in order that each of the parties may be fully advised of the other’s position. (3) The specific format for the discussions shall be left to the discretion of the designated State and Contractor representatives, but may include the preparation of agreed upon statements of fact or written statements of position. (4) Following the completion of this process within 60 calendar days, the Director of Procurement, DTMB, or designee, shall issue a written opinion regarding the issue(s) in dispute within 30 calendar days. The opinion regarding the dispute must be considered the State’s final action and the exhaustion of administrative remedies. (b) This Section shall not be construed to prevent either party from instituting, and a party is authorized to institute, formal proceedings earlier to avoid the expiration of any applicable limitations period, to preserve a superior position with respect to other creditors, or under Section 2.193. (c) The State shall not mediate disputes between the Contractor and any other entity, except state agencies, concerning responsibility for performance of work under the Contract.

2.193 INJUNCTIVE RELIEF

A claim between the State and the Contractor is not subject to the provisions of Section 2.192, Informal Dispute Resolution, where a party makes a good faith determination that a breach of the Contract by the other party will result in damages so immediate, so large or severe, and so incapable of adequate redress that a temporary restraining order or other injunctive relief is the only adequate remedy.

2.194 CONTINUED PERFORMANCE

Each party agrees to continue performing its obligations under the Contract while a dispute is being resolved except to the extent the issue in dispute precludes performance (dispute over payment must not be deemed to preclude performance) and without limiting either party’s right to terminate the Contract as provided in Section 2.150, as the case may be.

2.200 Federal and State Contract Requirements

2.201 NONDISCRIMINATION

In the performance of the Contract, Contractor agrees not to discriminate against any employee or applicant for employment, with respect to his or her hire, tenure, terms, conditions or privileges of employment, or any matter directly or indirectly related to employment, because of race, color, religion, national origin, ancestry, age, sex, height, weight, and marital status, physical or mental disability. Contractor further agrees that every subcontract entered into for the performance of this Contract or any purchase order resulting from this Contract will contain a provision requiring non-discrimination in employment, as specified here, binding upon each SubContractor. This covenant is required under the Elliot Larsen Civil Rights Act, 1976 PA 453, MCL 37.2101,


167

et seq., and the Persons with Disabilities Civil Rights Act, 1976 PA 220, MCL 37.1101, et seq., and any breach of this provision may be regarded as a material breach of the Contract.

2.202 UNFAIR LABOR PRACTICES

Under 1980 PA 278, MCL 423.321, et seq., the State shall not award a Contract or subcontract to an employer whose name appears in the current register of employers failing to correct an unfair labor practice compiled under section 2 of the Act. This information is compiled by the United States National Labor Relations Board. A Contractor of the State, in relation to the Contract, shall not enter into a contract with a SubContractor, manufacturer, or supplier whose name appears in this register. Under section 4 of 1980 PA 278, MCL 423.324, the State may void any Contract if, after award of the Contract, the name of Contractor as an employer or the name of the SubContractor, manufacturer or supplier of Contractor appears in the register.

2.203 WORKPLACE SAFETY AND DISCRIMINATORY HARASSMENT

In performing Services for the State, the Contractor shall comply with the Department of Civil Services Rule 2-20 regarding Workplace Safety and Rule 1-8.3 regarding Discriminatory Harassment. In addition, the Contractor shall comply with Civil Service regulations and any applicable agency rules provided to the Contractor. For Civil Service Rules, see http://www.mi.gov/mdcs/0,1607,7-147-6877---,00.html.

2.204 RESERVED

2.210 Governing Law

2.211 GOVERNING LAW

The Contract shall in all respects be governed by, and construed according to, the substantive laws of the State of Michigan without regard to any Michigan choice of law rules that would apply the substantive law of any other jurisdiction to the extent not inconsistent with, or pre-empted by federal law.

2.212 COMPLIANCE WITH LAWS

Contractor shall comply with all applicable state, federal and local laws and ordinances in providing the Services/Deliverables.

2.213 JURISDICTION

Any dispute arising from the Contract shall be resolved in the State of Michigan. With respect to any claim between the parties, Contractor consents to venue in Ingham County, Michigan, and irrevocably waives any objections it may have to the jurisdiction on the grounds of lack of personal jurisdiction of the court or the laying of venue of the court or on the basis of forum non conveniens or otherwise. Contractor agrees to appoint agents in the State of Michigan to receive service of process.

2.220 Limitation of Liability

2.221 LIMITATION OF LIABILITY

Neither the Contractor nor the State is liable to each other, regardless of the form of action, for consequential, incidental, indirect, or special damages. This limitation of liability does not apply to claims for infringement of United States patent, copyright, trademark or trade secrets; to claims for personal injury or damage to property caused by the gross negligence or willful misconduct of the Contractor; to claims covered by other specific provisions of this Contract calling for liquidated damages; or to court costs or attorneys' fees awarded by a court in addition to damages after litigation based on this Contract. The State's liability for damages to the Contractor is limited to the value of the Contract.

2.230 Disclosure Responsibilities


168

2.231 DISCLOSURE OF LITIGATION

Contractor shall disclose any material criminal litigation, investigations or proceedings involving the Contractor (and each SubContractor) or any of its officers or directors or any litigation, investigations or proceedings under the Sarbanes-Oxley Act. In addition, each Contractor (and each SubContractor) shall notify the State of any material civil litigation, arbitration or proceeding which arises during the term of the Contract and extensions, to which Contractor (or, to the extent Contractor is aware, any SubContractor) is a party, and which involves: (i) disputes that might reasonably be expected to adversely affect the viability or financial stability of Contractor or any SubContractor; or (ii) a claim or written allegation of fraud against Contractor or, to the extent Contractor is aware, any SubContractor by a governmental or public entity arising out of their business dealings with governmental or public entities. The Contractor shall disclose in writing to the DTMB Procurement Buyer any litigation, investigation, arbitration or other proceeding (collectively, "Proceeding") within 30 days of its occurrence. Details of settlements that are prevented from disclosure by the terms of the settlement may be annotated. Information provided to the State from Contractor’s publicly filed documents referencing its material litigation shall be deemed to satisfy the requirements of this Section. If any Proceeding disclosed to the State under this Section, or of which the State otherwise becomes aware, during the term of this Contract would cause a reasonable party to be concerned about: (a) the ability of Contractor (or a SubContractor) to continue to perform this Contract according to its terms

and conditions, or (b) whether Contractor (or a SubContractor) in performing Services for the State is engaged in conduct which

is similar in nature to conduct alleged in the Proceeding, which conduct would constitute a breach of this Contract or a violation of Michigan law, regulations or public policy, then the Contractor must provide the State all reasonable assurances requested by the State to demonstrate that:

(1) Contractor and its SubContractors will be able to continue to perform this Contract and any Statements of Work according to its terms and conditions, and

(2) Contractor and its SubContractors have not and will not engage in conduct in performing the Services which is similar in nature to the conduct alleged in the Proceeding.

(c) Contractor shall make the following notifications in writing: (1) Within 30 days of Contractor becoming aware that a change in its ownership or officers has occurred,

or is certain to occur, or a change that could result in changes in the valuation of its capitalized assets in the accounting records, Contractor must notify DTMB-Procurement.

(2) Contractor shall also notify DTMB Procurement within 30 days whenever changes to asset valuations or any other cost changes have occurred or are certain to occur as a result of a change in ownership or officers.

(3) Contractor shall also notify DTMB-Procurement within 30 days whenever changes to company affiliations occur.

2.232 CALL CENTER DISCLOSURE

Contractor and/or all subContractors involved in the performance of this Contract providing call or contact center services to the State shall disclose the location of its call or contact center services to inbound callers. Failure to disclose this information is a material breach of this Contract.

2.233 BANKRUPTCY

The State may, without prejudice to any other right or remedy, terminate this Contract, in whole or in part, and, at its option, may take possession of the “Work in Process” and finish the Works in Process by whatever appropriate method the State may deem expedient if: (a) the Contractor files for protection under the bankruptcy laws; (b) an involuntary petition is filed against the Contractor and not removed within 30 days; (c the Contractor becomes insolvent or if a receiver is appointed due to the Contractor's insolvency; (d) the Contractor makes a general assignment for the benefit of creditors; or (e) the Contractor or its affiliates are unable to provide reasonable assurances that the Contractor or its

affiliates can deliver the services under this Contract.


169

Contractor will fix appropriate notices or labels on the Work in Process to indicate ownership by the State. To the extent reasonably possible, materials and Work in Process shall be stored separately from other stock and marked conspicuously with labels indicating ownership by the State.

2.240 Performance

2.241 TIME OF PERFORMANCE

(a) Contractor shall use commercially reasonable efforts to provide the resources necessary to complete all Services and Deliverables according to the time schedules contained in the Contract or any Statement of Work issued under it and other Exhibits governing the work, and with professional quality.

(b) Without limiting the generality of Section 2.241, Contractor shall notify the State in a timely manner upon becoming aware of any circumstances that may reasonably be expected to jeopardize the timely and successful completion of any Deliverables/Services on the scheduled due dates in the latest State-approved delivery schedule and must inform the State of the projected actual delivery date.

(c) If the Contractor believes that a delay in performance by the State has caused or will cause the Contractor to be unable to perform its obligations according to specified Contract time periods, the Contractor must notify the State in a timely manner and must use commercially reasonable efforts to perform its obligations according to the Contract time periods notwithstanding the State’s failure. Contractor will not be in default for a delay in performance to the extent the delay is caused by the State.

2.242 SERVICE LEVEL AGREEMENT (SLA)

(a) SLAs will be completed with the following operational considerations:

(1) SLAs will not be calculated for individual Incidents where any event of Excusable Failure has been determined; Incident means any interruption in Services.

(2) SLAs will not be calculated for individual Incidents where loss of service is planned and where the State has received prior notification or coordination.

(3) SLAs will not apply if the applicable Incident could have been prevented through planning proposed by Contractor and not implemented at the request of the State. To invoke this consideration, complete documentation relevant to the denied planning proposal must be presented to substantiate the proposal.

(4) Time period measurements will be based on the time Incidents are received by the Contractor and the time that the State receives notification of resolution based on 24x7x365 time period, except that the time period measurement will be suspended based on the following: (i) Time period(s) will not apply where Contractor does not have access to a physical State Location

and where access to the State Location is necessary for problem identification and resolution. (ii) Time period(s) will not apply where Contractor needs to obtain timely and accurate information or

appropriate feedback and is unable to obtain timely and accurate information or appropriate feedback from the State.

(b) Chronic Failure for any Service(s) will be defined as three unscheduled outage(s) or interruption(s) on any individual Service for the same reason or cause or if the same reason or cause was reasonably discoverable in the first instance over a rolling 30 day period. Chronic Failure will result in the State’s option to terminate the effected individual Service(s) and procure them from a different vendor for the chronic location(s) with Contractor to pay the difference in charges for up to three additional months. The termination of the Service will not affect any tiered pricing levels.

(c) Root Cause Analysis will be performed on any Business Critical outage(s) or outage(s) on Services when requested by the Contract Compliance Inspector. Contractor will provide its analysis within two weeks of outage(s) and provide a recommendation for resolution.

(d) All decimals must be rounded to two decimal places with five and greater rounding up and four and less rounding down unless otherwise specified.


170

2.243 LIQUIDATED DAMAGES

The parties acknowledge that late or improper completion of the Work will cause loss and damage to the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result. Therefore, Contractor and the State agree that if there is late or improper completion of the Work and the State does not elect to exercise its rights under Section 2.152, the State is entitled to collect liquidated damages in the amount of $5,000.00 and an additional $100.00 per day for each day Contractor fails to remedy the late or improper completion of the Work. Unauthorized Removal of any Key Personnel It is acknowledged that an Unauthorized Removal will interfere with the timely and proper completion of the Contract, to the loss and damage of the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result of any Unauthorized Removal. Therefore, Contractor and the State agree that in the case of any Unauthorized Removal in respect of which the State does not elect to exercise its rights under Section 2.152, the State may assess liquidated damages against Contractor as specified below. For the Unauthorized Removal of any Key Personnel designated in the Contract or any Statement of Work issued under it, the liquidated damages amount is $25,000.00 per individual if the Contractor identifies a replacement approved by the State under Section 2.060 and assigns the replacement to the Project to shadow the Key Personnel who is leaving for a period of at least 30 days before the Key Personnel’s removal. If Contractor fails to assign a replacement to shadow the removed Key Personnel for at least 30 days, in addition to the $25,000.00 liquidated damages for an Unauthorized Removal, Contractor must pay the amount of $833.33 per day for each day of the 30 day shadow period that the replacement Key Personnel does not shadow the removed Key Personnel, up to $25,000.00 maximum per individual. The total liquidated damages that may be assessed per Unauthorized Removal and failure to provide 30 days of shadowing must not exceed $50,000.00 per individual.

2.244 EXCUSABLE FAILURE

Neither party will be liable for any default, damage or delay in the performance of its obligations under the Contract to the extent the default, damage or delay is caused by government regulations or requirements (executive, legislative, judicial, military or otherwise), power failure, electrical surges or current fluctuations, lightning, earthquake, war, water or other forces of nature or acts of God, delays or failures of transportation, equipment shortages, suppliers’ failures, or acts or omissions of common carriers, fire; riots, civil disorders; strikes or other labor disputes, embargoes; injunctions (provided the injunction was not issued as a result of any fault or negligence of the party seeking to have its default or delay excused); or any other cause beyond the reasonable control of a party; provided the non-performing party and its SubContractors are without fault in causing the default or delay, and the default or delay could not have been prevented by reasonable precautions and cannot reasonably be circumvented by the non-performing party through the use of alternate sources, workaround plans or other means, including disaster recovery plans. If a party does not perform its contractual obligations for any of the reasons listed above, the non-performing party will be excused from any further performance of its affected obligation(s) for as long as the circumstances prevail. But the party must use commercially reasonable efforts to recommence performance whenever and to whatever extent possible without delay. A party must promptly notify the other party in writing immediately after the excusable failure occurs, and also when it abates or ends. If any of the above-enumerated circumstances substantially prevent, hinder, or delay the Contractor’s performance of the Services/provision of Deliverables for more than 10 Business Days, and the State determines that performance is not likely to be resumed within a period of time that is satisfactory to the State in its reasonable discretion, then at the State’s option: (a) the State may procure the affected Services/Deliverables from an alternate source, and the State is not be liable for payment for the unperformed Services/ Deliverables not provided under the Contract for so long as the delay in performance continues; (b)


171

the State may terminate any portion of the Contract so affected and the charges payable will be equitably adjusted to reflect those Services/Deliverables terminated; or (c) the State may terminate the affected Statement of Work without liability to Contractor as of a date specified by the State in a written notice of termination to the Contractor, except to the extent that the State must pay for Services/Deliverables provided through the date of termination. The Contractor will not have the right to any additional payments from the State as a result of any Excusable Failure occurrence or to payments for Services not rendered/Deliverables not provided as a result of the Excusable Failure condition. Defaults or delays in performance by Contractor which are caused by acts or omissions of its SubContractors will not relieve Contractor of its obligations under the Contract except to the extent that a SubContractor is itself subject to an Excusable Failure condition described above and Contractor cannot reasonably circumvent the effect of the SubContractor’s default or delay in performance through the use of alternate sources, workaround plans or other means.

2.250 Approval of Deliverables

2.251 DELIVERY OF DELIVERABLES

A list of the Deliverables to be prepared and delivered by Contractor including, for each Deliverable, the scheduled delivery date and a designation of whether the Deliverable is a document (“Written Deliverable”) or a Custom Software Deliverable is attached, if applicable. All Deliverables shall be completed and delivered for State review and written approval and, where applicable, installed in accordance with the State-approved delivery schedule and any other applicable terms and conditions of this Contract. Prior to delivering any Deliverable to the State, Contractor will first perform all required quality assurance activities, and, in the case of Custom Software Deliverables, System Testing to verify that the Deliverable is complete and in conformance with its specifications. Before delivering a Deliverable to the State, Contractor shall certify to the State that (1) it has performed such quality assurance activities, (2) it has performed any applicable testing, (3) it has corrected all material deficiencies discovered during such quality assurance activities and testing, (4) the Deliverable is in a suitable state of readiness for the State’s review and approval, and (5) the Deliverable/Service has all Critical Security patches/updates applied. In discharging its obligations under this Section, Contractor shall be at all times (except where the parties agree otherwise in writing) in compliance with Level 3 of the Software Engineering Institute’s Capability Maturity Model for Software (“CMM Level 3”) or its equivalent.

2.252 CONTRACTOR SYSTEM TESTING

Contractor will be responsible for System Testing each Custom Software Deliverable in Contractor’s development environment prior to turning over the Custom Software Deliverable to the State for User Acceptance Testing and approval. Contractor’s System Testing shall include the following, at a minimum, plus any other testing required by CMM Level 3 or Contractor’s system development methodology: Contractor will be responsible for performing Unit Testing and incremental Integration Testing of the components of each Custom Software Deliverable. Contractor’s System Testing will also include Integration Testing of each Custom Software Deliverable to ensure proper inter-operation with all prior software Deliverables, interfaces and other components that are intended to inter-operate with such Custom Software Deliverable, and will include Regression Testing, volume and stress testing to ensure that the Custom Software Deliverables are able to meet the State’s projected growth in the number and size of transactions to be processed by the Application and number of users, as such projections are set forth in the applicable Statement of Work. Contractor’s System Testing will also include Business Function Testing and Technical Testing of each Application in a simulated production environment. Business Function Testing will include testing of full work streams that flow through the Application as the Application will be incorporated within the State’s computing


172

environment. The State shall participate in and provide support for the Business Function Testing to the extent reasonably requested by Contractor. Within ten (10) days before the commencement of Business Function Testing pursuant to this Section, Contractor shall provide the State for State review and written approval Contractor’s test plan for Business Function Testing. Within five (5) Business Days following the completion of System Testing pursuant to this Section, Contractor shall provide to the State a testing matrix establishing that testing for each condition identified in the System Testing plans has been conducted and successfully concluded. To the extent that testing occurs on State premises, the State shall be entitled to observe or otherwise participate in testing under this Section as the State may elect.

2.253 APPROVAL OF DELIVERABLES, IN GENERAL

All Deliverables (Written Deliverables and Custom Software Deliverables) require formal written approval by the State, in accordance with the following procedures. Formal approval by the State requires that the Deliverable be confirmed in writing by the State to meet its specifications, which, in the case of Custom Software Deliverables, will include the successful completion of State User Acceptance Testing, to be led by the State with the support and assistance of Contractor. The parties acknowledge that the approval process set forth herein will be facilitated by ongoing consultation between the parties, visibility of interim and intermediate Deliverables and collaboration on key decisions. The State’s obligation to comply with any State Review Period is conditioned on the timely delivery of Deliverables being reviewed. If Contractor fails to provide a Deliverable to the State in a timely manner, the State will nevertheless use commercially reasonable efforts to complete its review or testing within the applicable State Review Period. Before commencement of its review or testing of a Deliverable, the State may inspect the Deliverable to confirm that all components of the Deliverable (e.g., software, associated documentation, and other materials) have been delivered. If the State determines that the Deliverable is incomplete, the State may refuse delivery of the Deliverable without performing any further inspection or testing of the Deliverable. Otherwise, the review period will be deemed to have started on the day the State receives the Deliverable and the applicable certification by Contractor in accordance with this Section. The State will approve in writing a Deliverable upon confirming that it conforms to and, in the case of a Custom Software Deliverable, performs in accordance with, its specifications without material deficiency. The State may, but shall not be required to, conditionally approve in writing a Deliverable that contains material deficiencies if the State elects to permit Contractor to rectify them post-approval. In any case, Contractor will be responsible for working diligently to correct within a reasonable time at Contractor’s expense all deficiencies in the Deliverable that remain outstanding at the time of State approval. If, after three (3) opportunities (the original and two repeat efforts), Contractor is unable to correct all deficiencies preventing State approval of a Deliverable, the State may: (i) demand that Contractor cure the failure and give Contractor additional time to cure the failure at the sole expense of Contractor; or (ii) keep this Contract in force and do, either itself or through other parties, whatever Contractor has failed to do, in which event Contractor shall bear any excess expenditure incurred by the State in so doing beyond the contract price for such Deliverable and will pay the State an additional sum equal to ten percent (10%) of such excess expenditure to cover the State’s general expenses without the need to furnish proof in substantiation of such general expenses; or (iii) terminate this Contract for default, either in whole or in part by notice to Contractor (and without the need to afford Contractor any further opportunity to cure). Notwithstanding the foregoing, the State shall not use, as a basis for exercising its termination rights under this Section, deficiencies discovered in a repeat State Review Period that could reasonably have been discovered during a prior State Review Period. The State, at any time and in its own discretion, may halt the UAT or approval process if such process reveals deficiencies in or problems with a Deliverable in a sufficient quantity or of a sufficient severity as to make the continuation of such process unproductive or unworkable. In such case, the State may return the applicable


173

Deliverable to Contractor for correction and re-delivery prior to resuming the review or UAT process and, in that event, Contractor will correct the deficiencies in such Deliverable in accordance with the Contract, as the case may be. Approval in writing of a Deliverable by the State shall be provisional; that is, such approval shall not preclude the State from later identifying deficiencies in, and declining to accept, a subsequent Deliverable based on or which incorporates or inter-operates with an approved Deliverable, to the extent that the results of subsequent review or testing indicate the existence of deficiencies in the subsequent Deliverable, or if the Application of which the subsequent Deliverable is a component otherwise fails to be accepted pursuant to Section 2.080.

2.254 PROCESS FOR APPROVAL OF WRITTEN DELIVERABLES

The State Review Period for Written Deliverables will be the number of days set forth in the applicable Statement of Work following delivery of the final version of the Written Deliverable (failing which the State Review Period, by default, shall be five (5) Business Days for Written Deliverables of one hundred (100) pages or less and ten (10) Business Days for Written Deliverables of more than one hundred (100) pages). The duration of the State Review Periods will be doubled if the State has not had an opportunity to review an interim draft of the Written Deliverable prior to its submission to the State. The State agrees to notify Contractor in writing by the end of the State Review Period either stating that the Written Deliverable is approved in the form delivered by Contractor or describing any deficiencies that shall be corrected prior to approval of the Written Deliverable (or at the State’s election, subsequent to approval of the Written Deliverable). If the State delivers to Contractor a notice of deficiencies, Contractor will correct the described deficiencies and within five (5) Business Days resubmit the Deliverable in a form that shows all revisions made to the original version delivered to the State. Contractor’s correction efforts will be made at no additional charge. Upon receipt of a corrected Written Deliverable from Contractor, the State will have a reasonable additional period of time, not to exceed the length of the original State Review Period, to review the corrected Written Deliverable to confirm that the identified deficiencies have been corrected.

2.255 PROCESS FOR APPROVAL OF CUSTOM SOFTWARE DELIVERABLES

The State will conduct UAT of each Custom Software Deliverable in accordance with the following procedures to determine whether it meets the criteria for State approval – i.e., whether it conforms to and performs in accordance with its specifications without material deficiencies. Within thirty (30) days (or such other number of days as the parties may agree to in writing) prior to Contractor’s delivery of any Custom Software Deliverable to the State for approval, Contractor shall provide to the State a set of proposed test plans, including test cases, scripts, data and expected outcomes, for the State’s use (which the State may supplement in its own discretion) in conducting UAT of the Custom Software Deliverable. Contractor, upon request by the State, shall provide the State with reasonable assistance and support during the UAT process. For the Custom Software Deliverables listed in an attachment, the State Review Period for conducting UAT will be as indicated in the attachment. For any other Custom Software Deliverables not listed in an attachment, the State Review Period shall be the number of days agreed in writing by the parties (failing which it shall be forty-five (45) days by default). The State Review Period for each Custom Software Deliverable will begin when Contractor has delivered the Custom Software Deliverable to the State accompanied by the certification required by this Section and the State’s inspection of the Deliverable has confirmed that all components of it have been delivered. The State’s UAT will consist of executing test scripts from the proposed testing submitted by Contractor, but may also include any additional testing deemed appropriate by the State. If the State determines during the UAT that the Custom Software Deliverable contains any deficiencies, the State will notify Contractor of the deficiency by making an entry in an incident reporting system available to both Contractor and the State. Contractor will modify promptly the Custom Software Deliverable to correct the reported deficiencies, conduct appropriate System Testing (including, where applicable, Regression Testing) to confirm the proper correction of the deficiencies and re-deliver the corrected version to the State for re-testing in UAT. Contractor will


174

coordinate the re-delivery of corrected versions of Custom Software Deliverables with the State so as not to disrupt the State’s UAT process. The State will promptly re-test the corrected version of the Software Deliverable after receiving it from Contractor. Within three (3) business days after the end of the State Review Period, the State will give Contractor a written notice indicating the State’s approval or rejection of the Custom Software Deliverable according to the criteria and process set out in this Section.

2.256 FINAL ACCEPTANCE

“Final Acceptance” shall be considered to occur when the Custom Software Deliverable to be delivered has been approved by the State and has been operating in production without any material deficiency for fourteen (14) consecutive days. If the State elects to defer putting a Custom Software Deliverable into live production for its own reasons, not based on concerns about outstanding material deficiencies in the Deliverable, the State shall nevertheless grant Final Acceptance of the Project.

2.260 Ownership

2.261 OWNERSHIP OF WORK PRODUCT BY STATE

The State owns all Deliverables, as they are work made for hire by the Contractor for the State. The State owns all United States and international copyrights, trademarks, patents or other proprietary rights in the Deliverables.

2.262 VESTING OF RIGHTS

With the sole exception of any preexisting licensed works identified in the SOW, the Contractor assigns, and upon creation of each Deliverable automatically assigns, to the State, ownership of all United States and international copyrights, trademarks, patents, or other proprietary rights in each and every Deliverable, whether or not registered by the Contractor, insofar as any the Deliverable, by operation of law, may not be considered work made for hire by the Contractor for the State. From time to time upon the State’s request, the Contractor must confirm the assignment by execution and delivery of the assignments, confirmations of assignment, or other written instruments as the State may request. The State may obtain and hold in its own name all copyright, trademark, and patent registrations and other evidence of rights that may be available for Deliverables.

2.263 RIGHTS IN DATA

The State is the owner of all data made available by the State to the Contractor or its agents, SubContractors or representatives under the Contract. The Contractor will not use the State’s data for any purpose other than providing the Services, nor will any part of the State’s data be disclosed, sold, assigned, leased or otherwise disposed of to the general public or to specific third parties or commercially exploited by or on behalf of the Contractor. No employees of the Contractor, other than those on a strictly need-to-know basis, have access to the State’s data. Contractor will not possess or assert any lien or other right against the State’s data. Without limiting the generality of this Section, the Contractor must only use personally identifiable information as strictly necessary to provide the Services and must disclose the information only to its employees who have a strict need-to-know the information. The Contractor must comply at all times with all laws and regulations applicable to the personally identifiable information. The State is the owner of all State-specific data under the Contract. The State may use the data provided by the Contractor for any purpose. The State will not possess or assert any lien or other right against the Contractor’s data. Without limiting the generality of this Section, the State may use personally identifiable information only as strictly necessary to utilize the Services and must disclose the information only to its employees who have a strict need to know the information, except as provided by law. The State must comply at all times with all laws and regulations applicable to the personally identifiable information. Other material developed and provided to the State remains the State’s sole and exclusive property.


175

2.264 OWNERSHIP OF MATERIALS

The State and the Contractor will continue to own their respective proprietary technologies developed before entering into the Contract. Any hardware bought through the Contractor by the State, and paid for by the State, will be owned by the State. Any software licensed through the Contractor and sold to the State, will be licensed directly to the State.

2.270 State Standards

2.271 EXISTING TECHNOLOGY STANDARDS

The Contractor must adhere to all existing standards as described within the comprehensive listing of the State’s existing technology standards at http://www.michigan.gov/dmb/0,4568,7-150-56355-108233--,00.html;.

2.272 ACCEPTABLE USE POLICY

To the extent that Contractor has access to the State computer system, Contractor must comply with the State’s Acceptable Use Policy, see http://michigan.gov/cybersecurity/0,1607,7-217-34395_34476---,00.html. All Contractor employees must be required, in writing, to agree to the State’s Acceptable Use Policy before accessing the State system. The State reserves the right to terminate Contractor’s access to the State system if a violation occurs.

2.273 SYSTEMS CHANGES

Contractor is not responsible for and not authorized to make changes to any State systems without written authorization from the Project Manager. Any changes Contractor makes to State systems with the State’s approval must be done according to applicable State procedures, including security, access and configuration management procedures.

2.274 ELECTRONIC RECEIPT PROCESSING STANDARD

All electronic commerce applications that allow for electronic receipt of credit/debit card and electronic check (ACH) transactions must be processed via the Centralized Electronic Payment Authorization System (CEPAS).

2.280 Extended Purchasing Program

2.281 RESERVED

2.290 Environmental Provision

2.291 RESERVED

2.300 Deliverables

2.301 RESERVED

2.302 RESERVED

2.310 Software Warranties

2.311 PERFORMANCE WARRANTY

The Contractor represents and warrants that Deliverables, after Final Acceptance, will perform and operate in compliance with the requirements and other standards of performance contained in this Contract (including all descriptions, specifications and drawings made a part of the Contract) for a period of (90) ninety days. In the event of a breach of this warranty, Contractor will promptly correct the affected Deliverable(s) at no charge to the State.


176

2.312 NO SURREPTITIOUS CODE WARRANTY

The Contractor represents and warrants that no copy of licensed Software provided to the State contains or will contain any Self-Help Code or any Unauthorized Code as defined below. This warranty is referred to in this Contract as the “No Surreptitious Code Warranty.” As used in this Contract, “Self-Help Code” means any back door, time bomb, drop dead device, or other software routine designed to disable a computer program automatically with the passage of time or under the positive control of a person other than the licensee of the software. Self-Help Code does not include Software routines in a computer program, if any, designed to permit an owner of the computer program (or other person acting by authority of the owner) to obtain access to a licensee’s computer system(s) (e.g. remote access via modem) for purposes of maintenance or technical support. As used in this Contract, “Unauthorized Code” means any virus, Trojan horse, spyware, worm or other Software routines or components designed to permit unauthorized access to disable, erase, or otherwise harm software, equipment, or data; or to perform any other such actions. The term Unauthorized Code does not include Self-Help Code. Unauthorized Code does not include Software routines in a computer program, if any, designed to permit an owner of the computer program (or other person acting by authority of the owner) to obtain access to a licensee’s computer system(s) (e.g. remote access via modem) for purposes of maintenance or technical support. In addition, Contractor will use up-to-date commercial virus detection software to detect and remove any viruses from any software prior to delivering it to the State.

2.313 CALENDAR WARRANTY

The Contractor represents and warrants that all software for which the Contractor either sells or licenses to the State of Michigan and used by the State prior to, during or after the calendar year 2000, includes or shall include, at no added cost to the State, design and performance so the State shall not experience software abnormality and/or the generation of incorrect results from the software, due to date oriented processing, in the operation of the business of the State of Michigan. The software design, to insure calendar year rollover compatibility, shall include, but is not limited to: data structures (databases, data files, etc.) that provide 4-digit date century; stored data that contain date century recognition, including, but not limited to, data stored in databases and hardware device internal system dates; calculations and program logic (e.g., sort algorithms, calendar generation, event recognition, and all processing actions that use or produce date values) that accommodates same century and multi-century formulas and date values; interfaces that supply data to and receive data from other systems or organizations that prevent non-compliant dates and data from entering any State system; user interfaces (i.e., screens, reports, etc.) that accurately show 4 digit years; and assurance that the year 2000 shall be correctly treated as a leap year within all calculation and calendar logic.

2.314 THIRD-PARTY SOFTWARE WARRANTY

The Contractor represents and warrants that it will disclose the use or incorporation of any third-party software into the Deliverables. At the time of Delivery, the Contractor shall provide in writing the name and use of any Third-party Software, including information regarding the Contractor’s authorization to include and utilize such software. The notice shall include a copy of any ownership agreement or license that authorizes the Contractor to use the Third-party Software.

2.315 RESERVED

2.320 Software Licensing

2.321 RESERVED.


177

2.322 RESERVED

2.323 RESERVED

2.324 RESERVED

2.325 PRE-EXISTING MATERIALS FOR CUSTOM SOFTWARE DELIVERABLES

Neither Contractor nor any of its SubContractors shall incorporate any preexisting materials (including Standard Software) into Custom Software Deliverables or use any pre-existing materials to produce Custom Software Deliverables if such pre-existing materials will be needed by the State in order to use the Custom Software Deliverables unless (i) such pre-existing materials and their owners are identified to the State in writing and (ii) such pre-existing materials are either readily commercially available products for which Contractor or its SubContractor, as the case may be, has obtained a license (in form and substance approved by the State) in the name of the State, or are materials that Contractor or its SubContractor, as the case may be, has the right to license to the State and has licensed to the State on terms and conditions approved by the State prior to using such pre-existing materials to perform the Services.

2.330 Source Code Escrow

2.331 DEFINITION

“Source Code Escrow Package” shall mean: (a) A complete copy in machine-readable form of the source code and executable code of the Licensed

Software, including any updates or new releases of the product; (b) A complete copy of any existing design documentation and user documentation, including any updates or

revisions; and/or (c) Complete instructions for compiling and linking every part of the source code into executable code for

purposes of enabling verification of the completeness of the source code as provided below. Such instructions shall include precise identification of all compilers, library packages, and linkers used to generate executable code.

2.332 DELIVERY OF SOURCE CODE INTO ESCROW

Contractor shall deliver a Source Code Escrow Package to the Escrow Agent, pursuant to the Escrow Contract, which shall be entered into on commercially reasonable terms subject to the provisions of this Contract within (30) thirty days of the execution of this Contract.

2.333 DELIVERY OF NEW SOURCE CODE INTO ESCROW

If at anytime during the term of this Contract, the Contractor provides a maintenance release or upgrade version of the Licensed Software, Contractor shall within ten (10) days deposit with the Escrow Agent, in accordance with the Escrow Contract, a Source Code Escrow Package for the maintenance release or upgrade version, and provide the State with notice of the delivery.

2.334 VERIFICATION

The State reserves the right at any time, but not more than once a year, either itself or through a third party Contractor, upon thirty (30) days written notice, to seek verification of the Source Code Escrow Package.

2.335 ESCROW FEES

The Contractor will pay all fees and expenses charged by the Escrow Agent.

2.336 RELEASE EVENTS

The Source Code Escrow Package may be released from escrow to the State, temporarily or permanently, upon the occurrence of one or more of the following: (a) The Contractor becomes insolvent, makes a general assignment for the benefit of creditors, files a

voluntary petition of bankruptcy, suffers or permits the appointment of a receiver for its business or


178

assets, becomes subject to any proceeding under bankruptcy or insolvency law, whether domestic or foreign;

(b) The Contractor has wound up or liquidated its business voluntarily or otherwise and the State has reason to believe that such events will cause the Contractor to fail to meet its warranties and maintenance obligations in the foreseeable future;

(c) The Contractor voluntarily or otherwise discontinues support of the provided products or fails to support the products in accordance with its maintenance obligations and warranties.

2.337 RELEASE EVENT PROCEDURES

If the State desires to obtain the Source Code Escrow Package from the Escrow Agent upon the occurrence of an Event in this Section, then: (a) The State shall comply with all procedures in the Escrow Contract; (b) The State shall maintain all materials and information comprising the Source Code Escrow Package in

confidence in accordance with this Contract; (c) If the release is a temporary one, then the State shall promptly return all released materials to Contractor

when the circumstances leading to the release are no longer in effect.

2.338 LICENSE

Upon release from the Escrow Agent pursuant to an event described in this Section, the Contractor automatically grants the State a non-exclusive, irrevocable license to use, reproduce, modify, maintain, support, update, have made, and create Derivative Works. Further, the State shall have the right to use the Source Code Escrow Package in order to maintain and support the Licensed Software so that it can be used by the State as set forth in this Contract.

2.339 DERIVATIVE WORKS

Any Derivative Works to the source code released from escrow that are made by or on behalf of the State shall be the sole property of the State. The State acknowledges that its ownership rights are limited solely to the Derivative Works and do not include any ownership rights in the underlying source code.


179

Glossary Days Means calendar days unless otherwise specified.

24x7x365 Means 24 hours a day, seven days a week, and 365 days a year (including the 366th day in a leap year).

Additional Service Means any Services/Deliverables within the scope of the Contract, but not specifically provided under any Statement of Work, that once added will result in the need to provide the Contractor with additional consideration.

Audit Period See Section 2.110

Business Day

Whether capitalized or not, shall mean any day other than a Saturday, Sunday or State-recognized legal holiday (as identified in the Collective Bargaining Agreement for State employees) from 8:00am EST through 5:00pm EST unless otherwise stated.

Blanket Purchase Order

An alternate term for Contract as used in the States computer system.

Business Critical Any function identified in any Statement of Work as Business Critical. Chronic Failure Defined in any applicable Service Level Agreements.

Deliverable Physical goods and/or commodities as required or identified by a Statement of Work

DTMB Michigan Department of Technology, Management and Budget

Environmentally preferable products

A product or service that has a lesser or reduced effect on human health and the environment when compared with competing products or services that serve the same purpose. Such products or services may include, but are not limited to, those that contain recycled content, minimize waste, conserve energy or water, and reduce the amount of toxics either disposed of or consumed.

Excusable Failure See Section 2.244.

Hazardous material Any material defined as hazardous under the latest version of federal Emergency Planning and Community Right-to-Know Act of 1986 (including revisions adopted during the term of the Contract).

Incident Any interruption in Services.

ITB A generic term used to describe an Invitation to Bid. The ITB serves as the document for transmitting the RFP to potential bidders

Key Personnel Any Personnel designated in Article 1 as Key Personnel.

New Work Any Services/Deliverables outside the scope of the Contract and not specifically provided under any Statement of Work, that once added will result in the need to provide the Contractor with additional consideration.

Ozone-depleting substance

Any substance the Environmental Protection Agency designates in 40 CFR part 82 as: (1) Class I, including, but not limited to, chlorofluorocarbons, halons, carbon tetrachloride, and methyl chloroform; or (2) Class II, including, but not limited to, hydro chlorofluorocarbons

Post-Consumer Waste

Any product generated by a business or consumer which has served its intended end use, and which has been separated or diverted from solid waste for the purpose of recycling into a usable commodity or product, and which does not include post-industrial waste.

Post-Industrial Waste

Industrial by-products that would otherwise go to disposal and wastes generated after completion of a manufacturing process, but do not include internally generated scrap commonly returned to industrial or manufacturing processes.

Recycling

The series of activities by which materials that are no longer useful to the generator are collected, sorted, processed, and converted into raw materials and used in the production of new products. This definition excludes the use of these materials as a fuel substitute or for energy production.


180

Reuse Using a product or component of municipal solid waste in its original form more than once.

RFP Request for Proposal designed to solicit proposals for services Services Any function performed for the benefit of the State.

Source reduction Any practice that reduces the amount of any hazardous substance, pollutant, or contaminant entering any waste stream or otherwise released into the environment prior to recycling, energy recovery, treatment, or disposal.

State Location Any physical location where the State performs work. State Location may include state-owned, leased, or rented space.

SubContractor A company Contractor delegates performance of a portion of the Services to, but does not include independent Contractors engaged by Contractor solely in a staff augmentation role.

Unauthorized Removal

Contractor’s removal of Key Personnel without the prior written consent of the State.

Waste prevention Source reduction and reuse, but not recycling.

Waste reduction and Pollution prevention

The practice of minimizing the generation of waste at the source and, when wastes cannot be prevented, utilizing environmentally sound on-site or off-site reuse and recycling. The term includes equipment or technology modifications, process or procedure modifications, product reformulation or redesign, and raw material substitutions. Waste treatment, control, management, and disposal are not considered pollution prevention, per the definitions under Part 143, Waste Minimization, of the Natural Resources and Environmental Protection Act (NREPA), 1994 PA 451, as amended.

Work in Progress A Deliverable that has been partially prepared, but has not been presented to the State for Approval.

Work Product Refers to any data compilations, reports, and other media, materials, or other objects or works of authorship created or produced by the Contractor as a result of an in furtherance of performing the services required by this Contract.


181

Attachment 1 -Support Level Agreement

The following is in combination with or in addition to Section 1.104 Work and Deliverable.

The Contractor has formalized help desk and maintenance and support processes to best meet the needs of the State. Inherent within these processes are:

• A manned help desk accessible by phone or email, with a one-hour response to all customer inquiries;

• Atlassian JIRA for filing and tracking problems and trouble tickets;

• A formal process for working with the customer to triage and prioritize trouble calls; and

• A formal release schedule for each customer’s application to deliver enhancements and bug fixes.

The service level agreement to the Contractor’s support process is documented below:

Support Level Agreement

Support Component Service Level Metrics Other Considerations Help desk support Defect filing

• Help desk is staffed during normal business hours 7:00 AM to 5:00 PM, Monday through Friday • JIRA application is available 24 hours, 7 days a week for the client, or the Help Desk Coordinator, to file production defects. • A time critical production problem (defined by the user either in the help desk call or on the JIRA ticket) will result in a response from a KL&A support person within 1 hour of notification.

A user filed defect in JIRA, will result in an e-mail response back to the user acknowledging the filing and an e-mail to the lead support person for that application.

Problem triage and prioritization

Time critical problems will result in a KL&A support person being on-site within four hours of the initial contact. A KL&A support person will contact the client within 48 hours of non-critical production notification. Problems will be discussed in terms of complexity, production impact, and resource needs. Problems will be assigned to: • Break fixes for high impact problems. • A scheduled release previously agreed by the agency

Many of our support staff have VPN’s to the State network. As such, the defect remediation may be handled remotely without an on-site visit.

Release Planning

• Each agency will have a release schedule for their application. The release schedule will be mutually defined by KL&A and the agency at the start of each fiscal year. • Releases can include bug fixes and new enhancements. • A release plan, defining the scope of the release, will be documented before starting the release. • Formal user acceptance testing and acceptance (UAT) of the release elements will be performed before migration to production.

Releases are planned for every 3 to 6 months.

Problem resolution and testing

• All code fixes will migrate through the development and QA environments before migration to production. • Users will review and or perform UAT before migration. • DTMB procedures and processes will be performed for each release. KL&


182

Attachment 2 - Organizational Chart/Responsibility Matrix Contractor’s Organizational Chart


183

Contractor’s Responsibility Matrix


184

Appendix A - COST TABLES

Table 1: Summary of Contract Costs

No. Project Costs Cost ($)

A. Maintenance Support and Future Enhancement Services Breakdown provided in Table 2 and 3

$3,152,233.37

TOTAL COST $3,152,233.37

Table 2: Maintenance/Interface Support

(1/1/14-

9/30/14) (10/1/14-9/30/15)

(10/1/15-9/30/16)

(10/1/16-9/30/17)

(10/1/17-9/30/18)

(10/1/18-9/30/19)

Total Years

Maintenance/Interface Support (includes

Technical Support; Help Desk; Knowledge

Transfer/Training; Documentation)

$307,125 $409,500 $409,500 $409,500 $409,500 $409,500 $2,354,625

Grand Total Maintenance

Support $307,125 $409,500 $409,500 $409,500 $409,500 $409,500 $2,354,625*

Note: Should an agency discontinue usage of an application or an interface, the State’s payable amount for Maintenance/Interface Support shall be prorated at 1/30th of the monthly maintenance/interface charges for each calendar day.

Table 2b: Summary Costs for Each Agency for Annual Maintenance/Interface Support Costs Application

State State Police

MDNR

MDCH MDOT

MDARD

Treasury

Civil Service

DTMB LARA Total Annual Fees

Initial 9 Months Support

RPS $25,000

$12,000

$12,000

$20,000

$12,000

$81,000

$60,750

MIRS $15,000

$20,000

$15,000

$20,000

$20,000

$90,000

$67,500

Interfaces

$40,000

$44,000

$5,000

$74,500

$75,000

$238,500

$178,875

Total $65,000

$56,000

$12,000

$109,500

$12,000

$20,000

$15,000

$20,000

$20,000

$75,000

$409,500

$307,125


185

Table 2c: Specific Interface Cost Details Agency Interface Total Annual Fees 1st Initial Nine Month

Support (1/1/14-9/30/14) Secretary of State Star - $5,000

UCC - $5,000 Record Lookup - $20,000 Credit Card - $5,000 IRP - $5,000

$40,000 $30,000

State Police Crash - $10,000 LEIN - $10,000 Smartscan - $2,000 Sex Offender -$5,000 CCW/Alias - $5,000 CPLR - $2,000 MiTrain/e-Payment - $10,000

$44,000 $33,000

MDNR EJV $5,000 $3.750

MDCH PPRS – $15,000 PCRS - $15,000 QAA - $5,000 CEPAS - $12,000 CHAMPS – $7,500 DMS - $5,000 EMS - $5,000 ASAP - $10,000

$74,500 $55,875

LARA Radiation Safety - $15,000 Facility Engineering – Projects - $32,000 Facilities - $28,000

$75,000 $56,250

Total $233,500 $178,875

*The price quotes for the Maintenance and Support elements are for the existing agencies and named interfaces. Any changes in the composition of these elements may result in a change.

Table 3: Future Enhancements

Resource Type Not-to-Exceed Hourly Rate

($)

Project management $125 Business analysts $100 System analysts $100 Programmer/developers

$90

System Architects $115 Others: (List) below): Technical Writers $65 Junior Developers $70


186

The initial value of spending authority for future enhancement services to the Contract is $797,608.37. The State reserves the right to determine whether payment shall be made on a not to exceed firm fixed-hourly rate basis, or on completion and acceptance of specified deliverables for future enhancements. Future enhancement services may only be initiated upon mutually agreed and executed individual Statement(s) of Work (SOW) between the Contractor and the State. Once agreed to, the Contractor must not be obliged or authorized to commence any work to implement a SOW until authorized via a purchase order issued against this contract. The State shall have the right to hold back an amount equal to percent 5% of all amounts invoiced by Contractor for specified deliverables for future enhancements.

NOTES: 1. Not-to-Exceed Hourly Rates quoted are inclusive of Contractor staff and management overhead, travel

and all other expenses. 2. DTMB is not obligated to execute the contract for the full amount of spending authority for future

enhancements in the Contract. 3. The State reserves the right to add additional spending authority to the Contract. The State reserves

the right to add additional Position Types, other than the Position Types listed above. 4. Costs shall to be billed monthly at actual hours utilizing the quoted firm fixed hourly rates or on

completion and acceptance of specified deliverables. 5. Prices quoted will be firm for the entire length of the Contract. For any options to renew (see Section

2.002), prices may not be increased by more than the previous year’s Consumer Price Index (CPI) or 3%, whichever is lower.

CONTRACT CHANGE NOTICE - · PDF fileENTERPRISE PROCUREMENT Department of Technology,...

Documents

Transcript of CONTRACT CHANGE NOTICE - · PDF fileENTERPRISE PROCUREMENT Department of Technology,...