Final Draftbids.centerdigitalgov.com/Nav_DW_6-05-2008_00010_106476.doc · Web viewDiscuss why the software solution is preferred for the SIMS project. Incorporate how the solution

STATE OF MONTANAREQUEST FOR PROPOSAL (RFP)

FOR INFORMATION TECHNOLOGYRFP Number:RFP08-1606P

RFP Title:SOS INFORMATION MANAGEMENT SYSTEM

RFP Response Due Date and Time:FRIDAY, JULY 18, 20082:00 p.m., Local Time

Number of Pages: 69

ISSUING AGENCY INFORMATIONProcurement Officer:Penny Moon

Issue Date:June 4, 2008

State Procurement BureauGeneral Services Division

Department of AdministrationRoom 165, Mitchell Building

125 North Roberts StreetP.O. Box 200135

Helena, MT 59620-0135

Phone: (406) 444-2575Fax: (406) 444-2529TTY Users, Dial 711

Website: http://vendor.mt.gov/

INSTRUCTIONS TO OFFERORSReturn Sealed Proposal to:

State Procurement BureauGeneral Services Division

Department of AdministrationRoom 165, Mitchell Building

125 North Roberts StreetP.O. Box 200135

Helena, MT 59620-0135

Mark Face of Envelope/Package:

RFP Number: RFP08-1606PRFP Response Due Date: 07/18/08

Special Instructions:

IMPORTANT: SEE STANDARD TERMS AND CONDITIONS

OFFERORS MUST COMPLETE THE FOLLOWINGOfferor Name/Address: Authorized Offeror Signatory:

(Please print name and sign in ink)

Offeror Phone Number: Offeror FAX Number:

Offeror E-mail Address:

OFFERORS MUST RETURN THIS COVER SHEET WITH RFP RESPONSE

Revised 2/08

http://gsd.mt.gov/

TABLE OF CONTENTS

PAGE

Instructions to Offerors................................................................................................3

Schedule of Events.......................................................................................................4

Section 1: Project Overview and Instructions...........................................................51.0 Project Overview............................................................................................................................51.1 Contract Term................................................................................................................................51.2 Single Point of Contact..................................................................................................................51.3 Required Review...........................................................................................................................51.4 Pre-Proposal Conference..............................................................................................................61.5 General Requirements...................................................................................................................61.6 Submitting a Proposal....................................................................................................................71.7 Cost of Preparing a Proposal.........................................................................................................8

Section 2: RFP Standard Information.........................................................................92.0 Authority.........................................................................................................................................92.1 Offeror Competition.......................................................................................................................92.2 Receipt of Proposals and Public Inspection..................................................................................92.3 Classification and Evaluation of Proposals....................................................................................92.4 State’s Rights Reserved..............................................................................................................112.5 Department of Administration Powers and Duties.......................................................................112.6 Compliance with State of Montana IT Standards........................................................................11

Section 3: Scope of Project.......................................................................................133.0 Introduction..................................................................................................................................133.1 Project Management....................................................................................................................153.2 System Requirements.................................................................................................................273.3 Project Infrastructure...................................................................................................................373.4 Operational Support Requirements.............................................................................................45

Section 4: Offeror Qualifications/Informational Requirements..............................484.0 State’s Right to Investigate and Reject........................................................................................484.1 Offeror Qualifications/Informational Requirements......................................................................48

Section 5: Cost Proposal...........................................................................................505.0 Cost Proposal..............................................................................................................................505.1 Required Pricing Information.......................................................................................................505.2 Payment Schedule.......................................................................................................................51

Section 6: Evaluation Process...................................................................................526.0 Basis of Evaluation......................................................................................................................526.1 Evaluation Criteria.......................................................................................................................52

Appendix A - Standard Terms and Conditions.........................................................55Appendix B - Information Technology Contract.......................................................58

RFP08-1606P, SOS Information Management System, Page 2

INSTRUCTIONS TO OFFERORS

It is the responsibility of each offeror to:

Follow the format required in the RFP when preparing your response. Provide point-by-point responses to all sections in a clear and concise manner.

Provide complete answers/descriptions. Read and answer all questions and requirements. Don’t assume the State or evaluator/evaluation committee will know what your company capabilities are or what items/services you can provide, even if you have previously contracted with the State. The proposals are evaluated based solely on the information and materials provided in your response.

Use the forms provided, i.e., cover page, sample budget form, certification forms, etc.

Submit your response on time. Note all the dates and times listed in the Schedule of Events and within the document, and be sure to submit all required items on time. Late proposal responses are never accepted.

The following items MUST be included in the response to be considered responsive.Failure to include any of these items may result in a nonresponsive determination.

Signed Cover Sheet.

Signed Addenda (if appropriate).

Point-by-Point response to all sections and subsections (per Section 1.6.1).

Response to Appendices A & B (per Section 1.6.1).

Complete answers to all requirements of Sections 3, 4, and 5.

Correctly executed State of Montana “Affidavit for Trade Secret Confidentiality” form if claiming information to be confidential or proprietary (per Section 2.2).


SCHEDULE OF EVENTS

EVENT DATE

RFP Issue Date...........................................................................................June 4, 2008

Pre-Proposal Conference........................................................................June 13, 2008

Deadline for Receipt of Written Questions............................................June 18, 2008

Deadline for Posting Written Responses to the State’s Website ...........July 2, 2008

RFP Response Due Date...........................................................................July 18, 2008

Notification of Offeror Interviews/Product Demonstrations...............August 1, 2008

Offeror Interviews/Product Demonstrations.................................August 18-29, 2008

Intended Date for Contract Award................................................September 15, 2008


SECTION 1: PROJECT OVERVIEW AND INSTRUCTIONS

1.0 PROJECT OVERVIEW

The STATE OF MONTANA, Secretary of State’s Office (SOS) (hereinafter referred to as “the State”) is seeking a contractor to provide full life cycle system development services to develop and implement the SOS Information Management System (SIMS). The full life cycle services encompass the entire development effort, including gap analysis, conceptual design, preliminary system design, detail design, development, conversion, testing, implementation, and warranty. This system will wholly or partially replace 20+ separate systems that are currently in place to manage the primary business processes within SOS. This system will be comprised of business and financial processes and will have a large imaging component. A more complete description of the supplies and/or services sought for this project is provided in Section 3, Scope of Project. Proposals submitted in response to this solicitation must comply with the instructions and procedures contained herein.

1.1 CONTRACT TERM

The contract term is for a period of approximately three years beginning at time of contract execution and ending December 31, 2011. Renewals of the contract, by mutual agreement of both parties, may be made at one-year intervals, or any interval that is advantageous to the State. This contract, including any renewals, may not exceed a total of ten years, at the option of the State.

1.2 SINGLE POINT OF CONTACT

From the date this Request for Proposal (RFP) is issued until an offeror is selected and the selection is announced by the procurement officer, offerors are not allowed to communicate with any state staff or officials regarding this procurement, except at the direction of Penny Moon, the procurement officer in charge of the solicitation. Any unauthorized contact may disqualify the offeror from further consideration. Contact information for the single point of contact is as follows:

Procurement Officer: Penny MoonState Procurement BureauRoom 165, Mitchell Building

125 North RobertsPO Box 200135

Helena MT 59620-0135Phone: (406) 444-3313

Fax: (406) 444-2529E-mail: [email protected]

1.3 REQUIRED REVIEW

1.3.1 Review RFP. Offerors should carefully review the instructions, mandatory requirements, specifications, standard terms and conditions, and contract set out in this RFP and promptly notify the procurement officer identified above in writing or via e-mail of any ambiguity, inconsistency, unduly restrictive specifications, or error which they discover upon examination of this RFP. This should include any terms or requirements within the RFP that either preclude the offeror from responding to the RFP or add unnecessary cost. This notification must be accompanied by an explanation and suggested modification and be received by the deadline for receipt of written or e-mailed inquiries set forth below. The State will make any final determination of changes to the RFP.


mailto:[email protected]

1.3.2 Form of Questions. Offerors with questions or requiring clarification or interpretation of any section within this RFP must address these questions in writing or via e-mail to the procurement officer referenced above on or before Wednesday, June 18, 2008. Each question must provide clear reference to the section, page, and item in question. Questions received after the deadline may not be considered.

1.3.3 State’s Response. The State will provide an official written response by Wednesday, July 2, 2008 to all questions received by June 18, 2008. The State’s response will be by formal written addendum. Any other form of interpretation, correction, or change to this RFP will not be binding upon the State. Any formal written addendum will be posted on the State’s website alongside the posting of the RFP at http://gsd.mt.gov/osbs by the close of business on the date listed. Offerors must sign and return with their RFP response an Acknowledgment of Addendum for any addendum issued.

1.4 PRE-PROPOSAL CONFERENCE

An optional Pre-Proposal Telephone Conference Call will be conducted at the State Procurement Bureau Conference Room, Mitchell Building Room 165, 125 N Roberts, Helena MT, on Thursday, June 12, 2008 at 10:00 a.m., Mountain time. Offerors are encouraged to use this opportunity to ask clarifying questions, obtain a better understanding of the project, or to notify the State of any ambiguities, inconsistencies, or errors discovered upon examination of this RFP. All responses to questions at the Pre-Proposal Conference will be oral and in no way binding on the State. Participation in the conference call is optional. However, it is advisable that all interested parties participate. Please contact Penny Moon at [email protected] no later than close of business on June 9, 2008 to reserve a conference line. Only those with reservations will be able to participate in the conference call.

1.5 GENERAL REQUIREMENTS

1.5.1 Acceptance of Standard Terms and Conditions/Contract. By submitting a response to this RFP, offeror agrees to acceptance of the standard terms and conditions and contract as set out in Appendices A and B of this RFP. Much of the language included in the standard terms and conditions and contract reflects requirements of Montana law. Requests for additions or exceptions to the standard terms and conditions, contract terms, including any necessary licenses, or any added provisions must be submitted to the procurement officer referenced above by the date for receipt of written/e-mailed questions. Any request must be accompanied by an explanation of why the exception is being sought and what specific effect it will have on the offeror’s ability to respond to the RFP or perform the contract. The State reserves the right to address nonmaterial requests for exceptions with the highest scoring offeror during contract negotiation. Any material exceptions requested and granted to the standard terms and conditions and contract language will be addressed in any formal written addendum issued for this RFP and will apply to all offerors submitting a response to this RFP. The State will make any final determination of changes to the standard terms and conditions and/or contract.

1.5.2 Resulting Contract. This RFP and any addenda, the offeror’s RFP response, including any amendments, a best and final offer, and any clarification question responses shall be included in any resulting contract. The State’s contract, attached as Appendix B, contains the contract terms and conditions which will form the basis of any contract between the State and the highest scoring offeror. In the event of a dispute as to the duties and responsibilities of the parties under this contract, the contract, along with any attachments prepared by the State, will govern in the same order of precedence as listed in the contract.

1.5.3 Understanding of Specifications and Requirements. By submitting a response to this RFP, offeror agrees to an understanding of and compliance with the specifications and requirements described in this RFP.

1.5.4 Prime Contractor/Subcontractors . The highest scoring offeror will be the prime contractor if a contract is awarded and shall be responsible, in total, for all work of any subcontractors. All subcontractors, if


mailto:[email protected]

http://gsd.mt.gov/osbs/Default.asp

any, must be listed in the proposal. The State reserves the right to approve all subcontractors. The Contractor shall be responsible to the State for the acts and omissions of all subcontractors or agents and of persons directly or indirectly employed by such subcontractors, and for the acts and omissions of persons employed directly by the Contractor. Further, nothing contained within this document or any contract documents created as a result of any contract awards derived from this RFP shall create any contractual relationships between any subcontractor and the State.

1.5.5 Offeror’s Signature. The proposals must be signed in ink by an individual authorized to legally bind the business submitting the proposal. The offeror’s signature on a proposal in response to this RFP guarantees that the offer has been established without collusion and without effort to preclude the State of Montana from obtaining the best possible supply or service. Proof of authority of the person signing the RFP response must be furnished upon request.

1.5.6 Offer in Effect for 120 Days. A proposal may not be modified, withdrawn or canceled by the offeror for a 120-day period following the deadline for proposal submission as defined in the Schedule of Events, or receipt of best and final offer, if required, and offeror so agrees in submitting the proposal.

1.6 SUBMITTING A PROPOSAL

1.6.1 Organization of Proposal. Offerors must organize their proposal into sections that follow the format of this RFP, with tabs separating each section. A point-by-point response to all numbered sections, subsections, and appendices is required. If no explanation or clarification is required in the offeror’s response to a specific subsection, the offeror shall indicate so in the point-by-point response or utilize a blanket response for the entire section with the following statement:

“(Offeror’s Name)” understands and will comply.

An offeror making the statement “Refer to our literature…” or “Please see www…….com” may be deemed nonresponsive or receive point deductions. If making reference to materials located in another section of the RFP response, specific page numbers and sections must be noted. The Evaluator/Evaluation Committee is not required to search through literature or another section of the proposal to find a response.

1.6.2 Failure to Comply with Instructions. Offerors failing to comply with these instructions may be subject to point deductions. The State may also choose to not evaluate, may deem nonresponsive, and/or may disqualify from further consideration any proposals that do not follow this RFP format, are difficult to understand, are difficult to read, or are missing any requested information.

1.6.3 Multiple Proposals. Offerors may, at their option, submit multiple proposals, in which case each proposal shall be evaluated as a separate document.

1.6.4 Price Sheets. Offerors must respond to this RFP by utilizing the RFP Price Sheets found in Section 5. These price sheets will serve as the primary representation of each offeror’s cost/price, and will be used extensively during proposal evaluations. Additional information should be included as necessary to explain in detail the offeror’s cost/price.

1.6.5 Copies Required and Deadline for Receipt of Proposals. Offerors must submit one original proposal and nine copies to the State Procurement Bureau. In addition, one electronic copy on CD or memory stick in WORD format must also be submitted. If any confidential materials are included, per the requirements of Section 2.2.2, they must be submitted on a separate CD or memory stick. PROPOSALS MUST BE SEALED AND LABELED ON THE OUTSIDE OF THE PACKAGE to clearly indicate that they are in response to RFP08-1606P. Proposals must be received at the receptionist’s desk of the State Procurement Bureau prior to 2:00 p.m., local time, Friday, July 18, 2008. Facsimile responses to


requests for proposals are ONLY accepted on an exception basis with prior approval of the procurement officer.

1.6.6 Late Proposals. Regardless of cause, late proposals will not be accepted and will automatically be disqualified from further consideration. It shall be the offeror’s sole risk to assure delivery at the receptionist's desk at the designated office by the designated time. Late proposals will not be opened and may be returned to the offeror at the expense of the offeror or destroyed if requested.

1.7 COST OF PREPARING A PROPOSAL

1.7.1 State Not Responsible for Preparation Costs. The costs for developing and delivering responses to this RFP and any subsequent presentations of the proposal as requested by the State are entirely the responsibility of the offeror. The State is not liable for any expense incurred by the offeror in the preparation and presentation of their proposal or any other costs incurred by the offeror prior to execution of a contract.

1.7.2 All Timely Submitted Materials Become State Property. All materials submitted in response to this RFP become the property of the State and are to be appended to any formal documentation, which would further define or expand any contractual relationship between the State and offeror resulting from this RFP process.


SECTION 2: RFP STANDARD INFORMATION

2.0 AUTHORITY

This RFP is issued under the authority of section 18-4-304, MCA (Montana Code Annotated) and ARM 2.5.602 (Administrative Rules of Montana). The RFP process is a procurement option allowing the award to be based on stated evaluation criteria. The RFP states the relative importance of all evaluation criteria. Only the evaluation criteria outlined in this RFP will be used.

2.1 OFFEROR COMPETITION

The State encourages free and open competition among offerors. Whenever possible, the State will design specifications, proposal requests, and conditions to accomplish this objective, consistent with the necessity to satisfy the State’s need to procure technically sound, cost-effective services and supplies.

2.2 RECEIPT OF PROPOSALS AND PUBLIC INSPECTION

2.2.1 Public Information. All information received in response to this RFP, including copyrighted material, is deemed public information and will be made available for public viewing and copying shortly after the time for receipt of proposals has passed with the following three exceptions: (1) bona fide trade secrets meeting the requirements of the Uniform Trade Secrets Act, Title 30, chapter 14, part 4, MCA, that have been properly marked, separated, and documented; (2) matters involving individual safety as determined by the State; and (3) other constitutional protections. See section 18-4-304, MCA. The State will make a copier available for interested parties to use at $0.10 per page. The interested party is responsible for the cost of copies and to provide personnel to do the copying.

2.2.2 Procurement Officer Review of Proposals. Upon opening the proposals received in response to this RFP, the procurement officer in charge of the solicitation will review the proposals and separate out any information that meets the referenced exceptions in Section 2.2.1 above, providing the following conditions have been met:

Confidential information is clearly marked and separated from the rest of the proposal. The proposal does not contain confidential material in the cost or price section. An affidavit from an offeror’s legal counsel attesting to and explaining the validity of the trade secret claim

as set out in Title 30, chapter 14, part 4, MCA, is attached to each proposal containing trade secrets. Counsel must use the State of Montana “Affidavit for Trade Secret Confidentiality” form in requesting the trade secret claim. This affidavit form is available on the General Services Division’s website at: http://gsd.mt.gov/procurement/forms.asp or by calling (406) 444-2575.

Information separated out under this process will be available for review only by the procurement officer, the evaluator/evaluation committee members, and limited other designees. Offerors must be prepared to pay all legal costs and fees associated with defending a claim for confidentiality in the event of a “right to know” (open records) request from another party.

2.3 CLASSIFICATION AND EVALUATION OF PROPOSALS

2.3.1 Initial Classification of Proposals as Responsive or Nonresponsive. All proposals will initially be classified as either “responsive” or “nonresponsive,” in accordance with ARM 2.5.602. Proposals may be found nonresponsive at any time during the procurement process if any of the required information is not provided; the submitted price is found to be excessive or inadequate as measured by criteria stated in the


http://gsd.mt.gov/procurement/forms.asp

RFP; or the proposal is not within the plans and specifications described and required in the RFP. If a proposal is found to be nonresponsive, it will not be considered further.

2.3.2 Determination of Responsibility. The procurement officer will determine whether an offeror has met the standards of responsibility in accordance with ARM 2.5.407. Such a determination may be made at any time during the procurement process if information surfaces that would result in a determination of nonresponsibility. If an offeror is found nonresponsible, the determination must be in writing, made a part of the procurement file and mailed to the affected offeror.

2.3.3 Evaluation of Proposals. An evaluator/evaluation committee will evaluate the remaining proposals and recommend whether to award the contract to the highest scoring offeror or, if necessary, to seek discussion/negotiation or a best and final offer in order to determine the highest scoring offeror. All responsive proposals will be evaluated based on stated evaluation criteria. In scoring against stated criteria, the State may consider such factors as accepted industry standards and a comparative evaluation of all other qualified RFP responses in terms of differing price, quality, and contractual factors. These scores will be used to determine the most advantageous offering to the State. If an evaluation committee meets to deliberate and evaluate the proposals, the public may attend and observe the evaluation committee deliberations.

2.3.4 Completeness of Proposals. Selection and award will be based on the offeror’s proposal and other items outlined in this RFP. Submitted responses may not include references to information located elsewhere, such as Internet websites or libraries, unless specifically requested. Information or materials presented by offerors outside the formal response or subsequent discussion/negotiation or “best and final offer,” if requested, will not be considered, will have no bearing on any award, and may result in the offeror being disqualified from further consideration.

2.3.5 Achieve Passing Score. Any proposal that fails to achieve 60% of the total available points for Sections 3.0, 3.1, 3.2, 3.3, 3.4, 4.1.1, 4.1.2, 4.1.3, 4.1.5, or 4.1.6 will be eliminated from further consideration. A "fail" for any individual evaluation criteria may result in proposal disqualification at the discretion of the procurement officer.

2.3.6 Opportunity for Discussion/Negotiation and/or Oral Presentation/Product Demonstration. After receipt of all proposals and prior to the determination of the award, the State may initiate discussions with one or more offerors should clarification or negotiation be necessary. Offerors may also be required to make an oral presentation and/or product demonstration to clarify their RFP response or to further define their offer. In either case, offerors should be prepared to send qualified personnel to Helena, Montana, to discuss technical and contractual aspects of the proposal. Oral presentations and product demonstrations, if requested, shall be at the offeror’s expense.

2.3.7 Best and Final Offer. The Best and Final Offer is an option available to the State under the RFP process, which permits the State to request a best and final offer from one or more offerors if additional information is required to make a final decision. Offerors may be contacted asking that they submit their best and final offer, which must include any and all discussed and/or negotiated changes. The State reserves the right to request a “best and final offer” for this RFP, if any, based on price/cost alone.

2.3.8 Evaluator/Evaluation Committee Recommendation for Contract Award. The evaluator/ evaluation committee will provide a written recommendation for contract award to the procurement officer that contains the scores, justification, and rationale for the decision. The procurement officer will review the recommendation to ensure its compliance with the RFP process and criteria before concurring in the evaluator's/evaluation committee’s recommendation of the responsive and responsible offeror that achieves the highest score and is, therefore, the most advantageous to the State.

2.3.9 Request for Documents Notice. Upon concurrence with the evaluator's/ evaluation committee's recommendation, the procurement officer will issue a “Request for Documents Notice” to the highest scoring offeror to obtain the required documents/information, such as insurance documents, contract


performance security, an electronic copy of any requested material, i.e., RFP response, response to clarification questions, and/or best and final offer, and any other necessary documents. Receipt of the “Request for Documents Notice” does not constitute a contract and no work may begin until a contract signed by all parties is in place. The procurement officer will notify all other offerors of the State's selection.

2.3.10 Contract Execution. Upon receipt of all required materials requested in the “Request for Documents Notice," a formal contract utilizing the contract attached as Appendix B and incorporating the Standard Terms and Conditions attached as Appendix A, as well as the highest scoring offeror's response to the RFP, will be provided to the highest scoring offeror for signature. The highest scoring offeror will be expected to accept and agree to all material requirements contained in the contract and set out in Appendices A and B of this RFP. If the highest scoring offeror does not accept all material requirements, the State may move to the next highest scoring offeror, or cancel the RFP. Work under the contract may begin when the contract is fully executed, i.e., when the contract is signed by all parties.

2.4 STATE’S RIGHTS RESERVED

While the State has every intention to award a contract as a result of this RFP, issuance of the RFP in no way constitutes a commitment by the State of Montana to award and execute a contract. Upon a determination such actions would be in its best interest, the State, in its sole discretion, reserves the right to:

Cancel or terminate this RFP (section 18-4-307, MCA); Reject any or all proposals received in response to this RFP (ARM 2.5.602); Waive any undesirable, inconsequential, or inconsistent provisions of this RFP which would not have

significant impact on any proposal (ARM 2.5.505); Not award if it is in the best interest of the State not to proceed with contract execution (ARM 2.5.602); or If awarded, terminate any contract if the State determines adequate state funds are not available (section

18-4-313, MCA).

2.5 DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES

The Department of Administration is responsible for carrying out the planning and program responsibilities for information technology (IT) for state government. (Section 2-17-512, MCA) The Chief Information Officer is the person appointed to carry out the duties and responsibilities of the Department of Administration relating to information technology. The Department of Administration shall:

Review the use of information technology resources for all state agencies; Review and approve state agency specifications and procurement methods for the acquisition of

information technology resources; and Review, approve, and sign all state agency IT contracts and shall review and approve other formal

agreements for information technology resources provided by the private sector and other government entities.

2.6 COMPLIANCE WITH STATE OF MONTANA IT STANDARDS

The offeror is expected to be familiar with the State of Montana IT environment. All services and products provided as a result of this RFP must comply with all applicable State of Montana IT policies and standards in effect at the time the RFP is issued. The offeror must request exceptions to State IT policies and standards in accordance with Section 1.5 of this RFP. It will be the responsibility of the State to deny the exception request or to seek a policy or standards exception through the Department of Administration, Information Technology Services Division (ITSD). Offerors are expected to provide proposals that conform to State IT policies and standards. It is the intent of ITSD to utilize the existing policies and standards and not to routinely grant exceptions. The State reserves the right to address nonmaterial requests for exceptions with the highest


scoring offeror during contract negotiation.

The links below will provide information on State of Montana IT strategic plans, current environment, policies, and standards.

State of Montana Information Technology Strategic Planhttp://itsd.mt.gov/stratplan/statewideplan.asp

State of Montana Information Technology Environmenthttp://itsd.mt.gov/techmt/compenviron.asp

State of Montana IT Policieshttp://itsd.mt.gov/policy/itpolicy.asp

State of Montana Software Standardshttp://itsd.mt.gov/policy/software.asp


http://itsd.mt.gov/policy/software.asp

http://itsd.mt.gov/policy/itpolicy.asp

http://itsd.mt.gov/techmt/compenviron.asp

http://itsd.mt.gov/stratplan/statewideplan.asp

SECTION 3: SCOPE OF PROJECT

In order for the State to determine the capabilities of an offeror to provide the supplies and/or perform the services specified in Section 3 above, the offeror must respond to the following requests for information regarding its ability to meet the State's requirements. THE RESPONSE “(OFFEROR’S NAME)” UNDERSTANDS AND WILL COMPLY IS NOT APPROPRIATE FOR THIS SECTION.

(NOTE: Each item must be thoroughly addressed. Offerors taking exception to any requirements listed in this section may be found non-responsive or be subject to point deductions.)

3.0 INTRODUCTION

The goal of this project is to implement a quality system that meets the requirements set forth in this RFP within budget and time constraints while utilizing proven methodology to control, monitor and communicate project milestones. The Secretary of State (SOS) intends to acquire full life cycle development services to integrate software and hardware that will enable the Secretary of State’s Office to meet the requirements of the business processes conducted in the current business units. The full life cycle services encompass the entire development effort, including gap analysis, conceptual design, preliminary system design, detail design, development, conversion, testing, implementation, and warranty. This section of the RFP is divided into four parts:

3.1 Project Management – tasks related to running the project through and between all stages of development and production

3.2 System Requirements – system business flows and requirements3.3 Project Infrastructure – items and tasks related to system environment and infrastructure3.4 Operations – items and tasks related to system operations, maintenance and support

Included with this RFP are numerous reference documents which will expand upon the needs and requirements included in Section 3, and will provide additional information on our current business processes and volumes. The following reference documents can be found posted to the State Procurement Bureau’s website at http://gsd.mt.gov/osbs/Results.asp?CategoryID=14:

C – Acronyms and Terms – Terminology used in this RFP to describe the business environment and our required functionality.

D – Input Forms – Listing of input forms that must be processed by, accommodated by and incorporated into the system being procured by this RFP.

E – Current Environment – Overview of the current business environment, including processing volumes and batch jobs.

F – Conversion – Conversion Plan developed by the SOS team. Includes expectations that offeror is expected to meet (and preferably exceed) in terms of conversion methodology and an initial overview of legacy systems conversion.

G – Search Criteria – Minimum search criteria that proposed system must meet.H – Components – Listing of business processing items that must be included in the system, broken out using

the conceptual business model presented in this RFP. All business items in this appendix must be included in the proposed system even though the conceptual business model need not be followed exactly as presented.

I – Control Tables – Preliminary listing of expected tables used to drive this highly configurable code table driven system. This list contains minimums and is not an exclusive list. It is expected that the volume of code tables used to configure the behavior of the system will grow significantly from this list.

J- System Requirements Matrix – Table of requirements which must be met by proposed system.

The vision for this system is: Common workflow used for all incoming documents, whether they originate electronically or on paper


One accounting system for all transactions Reduce paper processing (passing, storing, retrieving) by heavily utilizing imaging technology One single integrated system for all business units One technology platform for all included business units Automated document and content retention Integration with State of Montana eGovernment Portal – including the capability for the eGovernement

Portal to interface with SIMS and with the Statewide Accounting, Budget and Human Resources System (SABHRS), specifically the enterprise PeopleSoft Financials system for electronic payment and filing of forms.

Primary business functions include but are not limited to:

Accounting: Transaction processing Customer account management Financial management reporting Integration with SABHRS PeopleSoft Financials Integration with imaging repository Integration with eGovernement payment portal

Business Processing: Lien filing Business filing Candidate filing Notary filing Service of Process filing Miscellaneous filing Order processing for all units Farm Bill production Subscription management Management Document imaging Imaging Document and content lifecycle retention eGovernment Payment Portal

The offeror must ensure that SIMS software encompasses the following processes as described in this RFP:

Account for, image, reconcile, validate, monitor, maintain, and report on documents that customers submit to SOS for processing:

Filing forms that are submitted on behalf of entities that want to: operate or discontinue a business entity in Montana register a business name register a trademark file a bond or affidavit file, amend, terminate, or otherwise alter a lien file, amend, terminate, or otherwise alter a notary public commission run for political office (candidates) serve a defendant (service of process) retain information in records management

Order forms for miscellaneous products and services (copies, maps, binders, voter file, apostille/authentication certifications; etc.).

Invoice statements that summarize customer account activity. Support documents (cover letters, Title 15 certificates, etc.).


Payments for SOS products and services. Generate and distribute notifications to customers. Provide intuitive and flexible reporting, extract, and query capabilities which utilize parameter driven criteria

wherever possible. Analyze system processes and data in order to improve efficiency, effectiveness, and integrity. Account for, track, monitor, maintain, and report on related administrative, analytical, and operational

information. Apply granular security rules to SIMS information. Maintain an audit trail. Apply retention rules to SIMS information (data, metadata, images, paper files, interface to microfilm) Execute and monitor batch processes. Exchange information between SIMS and external sources:

Conversions and integrations: Update SIMS database and/or image repository with information from external entities

Extracts: Generate extracts of SIMS data and/or images and Electronically send the extracts to external entities or Manually or electronically update external databases and/or image repositories

Interfaces: Interface electronically with external databases and/or repositories when validating and/or populating SIMS information.

3.0 Response Guideline: Describe understanding of and willingness to deliver the needs as described in this section and acknowledge reading, understanding and willingness to deliver the needs and information provided in all of the included appendices to this RFP.

3.1 PROJECT MANAGEMENT

The approach and methodology proposed by the offeror in response to the RFP must account for the components listed below. The offeror is expected to create and support all phases, associated deliverables and metrics as set forth by the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK). A detailed description of this methodology is available from PMI (www.pmi.org). If offeror is not using PMI’s PMBOK, submit a matrix mapping how each PMI phase and deliverable is met by the proposed methodology.

3.1.1 Methodology. Offeror proposal must provide detailed documentation that describes proposed methodology, all deliverables, metrics and documentation in a detail level to include, at a minimum, the following discipline areas or an equivalent as identified by the offeror:

3.1.1.1 Project Stages Initiate Plan Execute Control Close

3.1.1.2 Project Management Activities Project Management System Requirements Specification Risk Management Requirements Management Configuration Management and Change Control Communications Training Testing


Scope Management Schedule Cost Management Quality Management Resources Management System Development

3.1.1.3 Software Development Lifecycle Requirements Definition Planning Infrastructure Acceptance Deployment System Maintenance Test (implementation, result validation, cycle management) Quality Assurance Preliminary Architecture Database Design User Interface Design Resources (hardware, software, staff) Design Programming Unit Testing Module Integration Software Integration Testing Report and Interface Integration Report and Interface Testing System Integration System Testing Acceptance Testing Installation Closeout Warranty Maintenance

3.1.1 Response Guideline: Identify and describe the suggested methodology for project management and full system development life cycle. Include an explanation of how long the offeror has been using this implementation methodology and why they would recommend this implementation methodology for the project. Discuss how the methodology will be used by offeror to plan and design SIMS. Offeror must also include descriptions of deliverables, plans, schedules, metrics and other primary processes for each discipline area.

Offeror must include an estimated schedule for the project. The schedule must include each of the proposed phases – detail design, development, testing, pilots, one-time implementation tasks and warranty periods. The offeror must demonstrate their ability to meet the schedule, and must also justify their project plan through documented application of an estimation methodology and any associated metrics.

3.1.2 Project Start Up. Offeror proposal must include an explanation of how offeror will initiate the project and get up to speed on the analysis accomplished to date by the SOS. The offeror must plan a three week requirements review period in which the entire project team (SOS and offeror) will review all requirements together to ensure that everyone fully understands the business requirements as set forth by this RFP.


The Secretary of State expects the requirement details to be flexible up to a defined point where a baseline is set. During the early months of the project we will work together to resolve any areas which do not have a clear and agreed upon implementation approach (Note that while the requirements detail will evolve, the foundation and scope established by these business requirements will remain the same). Offeror proposal in response to the RFP must describe the design process that will be used by offeror to refine requirements prior to construction.

Offeror project plan must include a period of time for forms redesign. In this effort, the 200 +/- forms used by customers to conduct business with the office are expected to be normalized as much as possible and redesigned to reflect the SIMS system fields, nomenclature, efficiencies and processing needs. In addition, detailed analysis of the use of standardized receipting forms or areas on each form must be included in this process. Preliminary standard receipting form analysis has been performed by SOS staff and will be used by offeror in this detailed analysis and design process.

Future system development of external systems with which SIMS interfaces, SOS management decisions, legislative mandates, and statutory restrictions may impact the requirements. Offeror proposal in response to the RFP must describe the process that will be used to manage changes to requirements before and after the requirements baseline is set.

3.1.2 Response Guideline: SOS would like to know how you expect to transition into this project and if you have transitioned into a project of this size and scope in the past. We would like to know how you plan to work with the SOS team to get a greater understanding of the meaning of all of the information and requirements included in this RFP. Although we have diligently crafted this document we are aware of the risks that can be incurred if there are misunderstandings of requirements, meaning or intent in written words. Offeror proposal must describe the tasks included in the proposed project plan that will address required activities described in this section.

3.1.3 Training . Offeror will track and resolve all training-related tasks as listed below. This training will ensure end-users are adequately trained in the use of components or functions added or implemented to SIMS. The selected offeror will update all training tools and manuals, and other materials in a timely and accurate fashion. All updated materials must be delivered to the SOS Project Manager. SOS will approve all updated training materials for accuracy, ease of use, and completeness.

Training Requirements: Design and deliver onsite training to all users of the system including front-line and administrative, and

technical support end-users. Train users at transition points between system life cycle stages, including the onset of system test,

acceptance test, and as part of the implementation of any phase into a pilot or production state. Write and provide a training plan based on proven methodology and provide details about:

o A proposed training schedule.o Training curricula.o Means of delivering training (including pre-course, online help guides, classroom, “hands on”

and distance learning activities, etc.). SOS is looking for solutions with online help, practice areas, and online tutorials that employees can utilize from their desk instead of at a central training location.

o Handouts and instructional aides.o Instructor qualifications (résume, experience, etc.)o Training evaluation criteria.o Post-training support options.o Provide and pay for all necessary labor, travel expenses, supplies and materials necessary for

the training. Materials:


o Create, maintain and update each of the users’ manuals, data flow diagrams, system documentation (as defined in the system documentation section of this RFP to ensure new procedures, screens, etc. are included.

o Create, maintain and update all reference materials utilized in the SOS training program.

Offeror will be responsible for maintaining on-line help screens and must ensure that hardcopy users’ guides reflect, including coordination of on-line help changes. The offeror’s proposal in response to the RFP must include a process which allows for the design, testing and acceptance of on-line help information.

3.1.3 Response Guideline: SOS would like to know how you plan to manage the training initiative for all aspects and phases of the project. Describe your experiences in training staff and producing the materials as described in this section of the RFP. Provide examples of training materials created by your company which were used on projects of similar size and scope.

3.1.4 System Design Changes . After SOS has accepted the offeror’s system design specifications, no substantial changes shall be made to the system design unless system design change specifications are made in accordance with the procedure described below. Changes needed to accommodate later in-scope system development phases are not considered to be system changes.

The selected offeror is encouraged to propose system design change specifications which will improve system functionality or performance. Use of an automated change management system is preferred.

If SOS and the selected offeror mutually agree to a change, and if the change falls outside of scope and costs have increased/decreased or the contract is otherwise affected, then SOS staff will modify the contract using the proposed change documentation. SOS will incorporate the change using a Contract Change Notice and\or an Advice of Change to Contract which will be define and clarified in the contract resulting from this RFP. However, system design changes that fall within scope or that are made for the correction of software faults or insufficient capacity must be corrected by the offeror at its own expense.

If prices for the proposed change are not acceptable to SOS, then the necessary modifications or additional work shall be subject to negotiation and/or competitive bidding.

At a minimum, the change process must involve an approval step from the SOS Project Manager. The offeror must not start, and SOS will not pay, for any work on proposed changes until SOS approval has been obtained. Work that is initiated before approval shall be included in the system at no cost to SOS.

3.1.4 Response Guideline: SOS would like to know how you plan to manage any changes that may occur during the life cycle of the project. Please describe and include examples of your proposed change management methodology. Describe how that methodology meets the needs outlined in this section.

3.1.5 Testing Requirements. The implementation of the accounting and business solutions will go through many phases of testing by both parties. The selected offeror and SOS will work together to build the user acceptance testing criteria. Time must be built into the project schedule to adequately monitor and evaluate the testing to ensure that the system conforms to all of the requirements SOS has documented for the solution.

3.1.5.1 System Performance During Testing. By the end of each testing phase, the system will be expected to perform successfully, meeting all expected results as defined in the test plans and scripts, under all operational conditions in accordance with SOS requirements; manufacturer’s operating instructions, and successful offeror’s technical and user specifications. Each project life cycle phase must pass defined test criteria according to test plans and test scripts before the SOS project manager authorizes the offeror to proceed with the next phase along the project life cycle. If, during the acceptance testing, the system fails to meet the requirements as defined by this RFP and subsequent change documents, SOS shall have the option


of granting the offeror an opportunity to repair and/or modify the system and restart the testing. At any time during the acceptance testing, and at its sole discretion, SOS retains the option of deeming the system unacceptable and canceling the acceptance testing and subsequent acquisition of the system according to the terms of Contract Termination and Event of Breach clauses.

3.1.5.2 Related Expenses. The offeror shall provide and pay for their employees’ labor, travel, equipment (if supplied by the offeror), supplies and materials necessary for the testing phases. SOS will pay those costs for SOS employees.

3.1.5.3 Testing Plan Outline. Offeror proposal in response to the RFP must include an outline of a testing plan that has been used in another jurisdiction to implement a project of similar size and scope. That plan must include sample tasks for the following stages but is not limited to just those stages:

Unit test System test User acceptance testing Pilot test requirements (If a pilot was used include the number of pilot sites)

3.1.5 Response Guideline: SOS would like to know how you plan to manage the test cycles that must be conducted to ensure that the system meets the acceptance testing criteria. You must specify the resources expected to conduct these tests (SOS or offeror, specifying roles individuals hold on the project). In addition, describe how your testing methodology will ensure the system meets acceptance testing criteria.

3.1.6 System Acceptance. System acceptance will be judged for SOS by a panel of internal and external user representatives selected by the SOS project manager. Acceptance will be based upon the system’s ability to meet the functional and operational requirements as listed within the RFP and its amendments, if any, and according to mutually defined system acceptance criteria. System acceptance testing shall include demonstration of adequate capacity, interaction, and performance of hardware, data communications, and software supplied by the offeror.

Tentative system acceptability will be evaluated by SOS staff at the completion of each development phase. At the end of each phase, the offeror will submit a request for the acceptance of completed system components to the SOS Project Manager. The acceptance request will be submitted by offeror along with supporting test data and system documentation as described in the system documentation section of this RFP.

Conclusive system acceptability for each phase will not be granted until the milestones proposed by offeror have been completed and approved by SOS project manager according to the agreed upon acceptance criteria. The warranty period for each phase begins upon acceptance of each phase, and includes all phases implemented prior to the phase currently being added to the suite of warranted phases. Acceptance at one phase does not preclude changes to accepted system components in order to meet the requirements of subsequent phases. If those changes are within scope, they will be made at no cost to SOS. SOS acceptance at each phase will be based on cumulative development through that phase. Each phase will be tested, and accepted as a whole by SOS. Non-acceptance of the phase as a whole will delay payments to offeror until the phase is accepted.

3.1.6 Response Guideline: Large application development projects that are deployed using phased release schedule can be difficult to staff and manage due to the vast array of work that must be completed, tested, and deployed simultaneously. Describe the acceptance methodology you will apply to this project in order to enable SOS to fully verify that all requirements in this RFP are met. Describe how you will support and warrant each phase during the cyclical life cycle stages of the project. Include a description of tasks, staffing and refer to sections in the proposed methodology that will support the project.

3.1.7 Final Acceptance. Final acceptance is required in order to complete this contract and to verify that the proposed solution has met the requirements and needs set forth in this RFP.


The State defines Final Acceptance and the start of the warranty period of the completed integrated SOS system (all phases) as the State’s written acknowledgement that:

All acceptance criteria have been successfully met, changed or waived. The completed integrated system has been in successful production for 90 consecutive days with an

absence of problems or defects (as defined and determined by the State) of all the following types during that period:

o No occurrence of failure or defect that has mission critical impacts.o No occurrence of failure or defect that is critical for business continuity.o No occurrence of failure or defect that creates an instance where an entire application or part

cannot be used.o No occurrence of failure or defect where an acceptable workaround has not been provided.

Also within the same 90 consecutive days:o The system must have processed three month-end cycles, and at least one quarter-end cycle.o The system must meet levels of system availability, application response time, and other

performance criteria specified in this RFP.

3.1.7 Response Guideline: In order to protect the investment SOS makes in this project, SOS must be able to verify and document that the system meets the requirements and needs set forth in this RFP. Describe your methodology for SOS to verify that the system has been successfully completed. Include descriptions of processes that will be conducted by offeror and SOS staff and descriptions of processes and documentation the offeror will use to facilitate and complete this task. Indicate your acceptance of the Final Acceptance criteria listed above.

3.1.8 Enhancements. SOS has specified the functional and business requirements for SIMS as thoroughly as possible while leaving room for joint refinement, within scope. However, SOS expects the experience with the new system will reveal functional design enhancements or new capabilities which would be useful to SOS and that fall outside of scope.

Contemplated enhancements are for changes in functionality or capacity beyond those anticipated in this RFP. They are not for correction of offeror errors, insufficient capacity or for refinements within scope that are made jointly by the offeror/SOS development team, all of which must be corrected by the offeror at their own expense

3.1.8.1 Enhancement Proposals . The offeror or SOS may identify desirable system enhancements or extensions. The selected offeror is encouraged to propose enhancements to system functionality. SOS also may desire certain extensions to SIMS. SOS may choose to implement such extensions or enhancements under this contract, but reserves the right to contract separately for these services.

In the event that an enhancement is proposed, the change management process proposed in response to this RFP (and clarified in the contract resulting from this RFP) must be followed by SOS and offeror staff, and must include at least the following procedure before work on the identified enhancement can begin:

The selected offeror will prepare a System Enhancement Proposal that provides at a minimum the following information for the proposed enhancement:

o Description of the enhancement, including impact if not doneo Scopeo Benefits and drawbackso Effects on current designo Impacts on completed system componentso Costso Impacts to hardware and software (including capacity)o Effects on SOS staffing and skill requirements


o Project scheduleo Training requirements

Like many other State agencies, SOS may be asked to provide information (typically ad hoc query driven reports) during the legislative session on very short notice (may require a response in less than a 24-hour period). Offeror must provide an hourly rate in their proposal in response to the RFP for ad hoc on demand reporting needs.

3.1.8 Response Guideline: In order to control the scope of this project, the change management processes must be very clearly defined and communicated by the offeror. Describe the methodology that will be used by the offeror to facilitate and control changes to the design of this system. Describe your experience in managing change on projects of this size and scope. The description must include but is not limited to the information and needs described above and must outline the tasks that will be performed by SOS and/or offeror staff. Include hourly rates for ad hoc reporting in the cost proposal included in the response to this RFP.

3.1.9 Enhancement Acceptance . If SOS and the selected offeror mutually agree to the enhancement proposal, then the contract will be modified by SOS staff, incorporating the change using the change management process proposed in response to this RFP (and clarified in the contract resulting from this RFP). If costs associated with the proposed enhancement are not acceptable to SOS, then the necessary modifications or additional work shall be open to negotiation and/or competitive bidding, even if first proposed by the offeror.

Offeror must not start, and SOS will not pay, for any work on proposed changes until SOS approval has been obtained. Work that is initiated before approval shall be included in the system at no cost to SOS.

3.1.9 Response Guideline: Describe the acceptance methodology you will apply to the enhancement process. At a minimum, offeror must convey acceptance to the requirements of this section.

3.1.10 System Warranty. As part of the submission that is provided in response to this RFP, the offeror must provide in detail the full terms, provisions and time periods associated with one or more system warranty period(s) that is/are included with the purchase, including variances, if any, for warranty coverage provided for software and/or other specified subcategories of equipment. Warranty includes:

Keeping key staff located in the Helena office for the duration of the warranty period to provide software and database support for system functionality including instances where it is not performing to its required intent as defined in the RFP, proposal, contract and design specifications.

Correction of all deficiencies in the system as provided in the contract and as identified by SOS at no cost to SOS.

Acceptance criteria must be met in order for the final acceptance of the warranty to be granted. The warranty period may be extended by the State for functionality that is not performing to its required intent as defined in the RFP, proposal, contract and design specifications at no cost to SOS until the offeror corrects all deficiencies and the system operates without a defect for 90 days.


3.1.10 Response Guideline: SOS requires the offeror to warranty the system they are contracted to produce. This warranty is in place to protect SOS from issues with the system in the early periods of its post-implementation existence.

SOS expects each phase of the system to be supported and warranted, and for the entire system to be supported and warranted as a whole after final acceptance. SOS desires ongoing warranty for each phase after it is released into production, and a one year warranty for the entire system upon final acceptance. Offeror may propose alternate time periods and/or warranty structures and must explain in detail the reasoning behind the proposed structure. Describe your experience and provide examples of providing warranty services to systems of this size, scope, and implementation structure (phased or single deployment).

SOS is concerned that subsequent phase development may pull resources from the support of those phases that have been deployed to production. Offeror must dedicate staff to existing releases with senior level developers that have at least six months of SIMS experience for the duration of each warranty period. This will ensure that those phases that have been deployed into production do not suffer due to the offeror’s desire to implement future system releases. Describe in detail how your staffing matrix will meet our desire to support all phases of development as described in this section.

Offeror must provide rates and a proposal for ongoing maintenance for 36 months following the warranty phase for the system as a whole. Describe the services proposed. Describe how work would be conducted during this time period. Describe aspects that must be considered and the methods that must be used by the offeror or SOS to estimate future costs for system maintenance/upgrades once the anticipated warranty has expired. These costs must be included in the cost proposal included with this response to this RFP.

3.1.11 Roles and Responsibilities. SOS expects its staff to participate fully in system design and development in order to ensure that the system meets SOS expectations and that SOS staff are intimately familiar with the system when it becomes operational. SOS may designate up to two FTE analysts, in addition to the SOS Project Manager, to participate in the design, development and implementation of SIMS. SOS analysts will not be expected to assist in the offeror's work, but must be allowed to participate with the offeror's team in all phases of design, development and implementation in order to become intimately familiar with the system. SOS analysts must be allowed to participate in appropriate meetings of the offeror’s team addressing system design, development, and implementation. If these meetings occur off site from Helena, then teleconference (preferably video teleconference) must be supplied by the offeror. The offeror must allow additional SOS staff, designated by SOS, to monitor specific aspects of the project, including, but not limited to, database implementation, accounting, security, auditability, and data communications.

In addition to the analytic staff, SOS intends to have at least one and may have two FTE IT staff dedicated to system development. Offeror must mentor SOS development staff in all aspects of system development so that SOS staff are in a position to take over the system at the end of the final contract warranty period. SOS staff must be considered part of the project team and will adhere to offeror methodology and processes. Offeror must train SOS development staff in methodology and processes to be used, and must recommend training for development tools proposed for project (database, front-end, any other integration tools). Offeror must provide side-by-side development and supervision of module modifications for four months for each SOS developer on the project. This mentoring period is not to exceed final system acceptance. To account for possible turnover, mentoring is expected for up to four different SOS developers over the contract period.

The State reserves the right to hire an independent verification and validation (IV&V) company to provide outside project oversight to ensure the offeror follows approved project and life cycle methodologies. As part of the IV&V process, the State reserves the right to apply code analyzers, profilers, and test support tools to verify that the offeror’s solution meets the technical and functional requirements contained within this RFP.


The offeror shall state if they agree with the roles identified in the table below and if they disagree, identify the reason and the modification, or addition to any of the roles identified below in their response.

Lead (L) shall mean the party with primary responsibility and ownership for the effort. Such assistance includes the contribution of skills and resources to complete the project in accordance with the technical and functional requirements detailed within this RFP.

Support (S) shall mean the party with supporting roles in the performance of the effort. Such assistance includes the contribution of skills and resources to complete the project in accordance with the technical and functional requirements detailed within this RFP.

Roles and Responsibilities3rd Party

IV&V Offeror StateI. Program Management A. Operate Program Management Office (PMO) S LB. Manage Offeror component of Project Team L SC. Manage State component of Project Team S LII. Independent Validation and Verification (IV&V) A. Perform project IV&V if the State exercises its option for requiring this

type of oversight.L S S

III. Technology Management A. Recommend technology platform that best meets SOS business needs

and expense/service level expectations L S

B. Authorize and approve technology platform S LC. Recommend policies and procedures S LD. Authorize and approve policies and procedures S LE. Define services and standards S LF. Manage/track development requests and orders S LIV. Planning/Requirements/Design A. Design data structures L SB. Design program modules L SC. Determine & manage functional requirements S LD. Recommend service level requirements L SE. Authorize and approve requirements definition S LF. Develop cost/benefit analysis S LG. Obtain management authorization S LV. Programming A. Develop functional specifications L SB. Create program code L SC. Conduct unit testing of modules L SD. Transfer programs to Offeror Quality Assurance L SE. Develop version control methodology L SVI. Software Integration & Testing A. Test system conformance to functional requirements L SB. Test system conformance to usability standards L SC. Conduct user acceptance testing S LD. Ensure system conformance to naming/operational conventions S LE. Review and approve quality assurance testing S LF. Repair defects L SContinued on next page….


Roles and Responsibilities 3rd Party IV&V Offeror StateVII. Implementation A. Install local system components as needed S LB. Train local system users L SC. Provide in-person assistance during initial implementation period

L S

D. Review and approve application implementation S LE. Develop disaster recovery plan and procedures S LVIII. Data Base Administration A. Perform data modeling L SB. Create logical database design L SC. Create physical database design L SD. Determine data element naming conventions L SE. Determine data element access levels L SF. Monitor compliance with naming conventions S LG. Determine logical views of database L SH. Recommend DBMS/tools for implementation L SI. Perform technical review of DBMS code L SJ. Monitor DBMS performance L SK. Recommend DBMS performance optimization measures L SL. Design database backup and recovery procedures L SM. Develop database backup and recovery procedures S LN. Assist in test-to-production application turnover L SO. Provide technical support of DBMS as needed L SIX. Data Conversion & Quality A. Recommend data conversion strategies L SB. Perform data conversion extract and minor cleaning S LC. Perform data conversion transform, import and loading L SD. Perform data cleansing S LE. Perform data validation S LX. Accounting & Reporting A. Assign user account codes S LB. Maintain tables of client account codes S LC. Maintain and allocate budget S LD. Track utilization S LE. Monitor cost center invoices S LF. Send invoices L SG. Respond to the State’s stakeholder inquiries S LH. Report on project execution metrics S LI. Provide status reports and metrics L SJ. Provide state agency status reports S L

Continued on next page….


Roles and Responsibilities3rd Party IV&V Offeror State

XI. Change Management Control A. Establish change management controls L SB. Establish change requirements L SC. Determine and manage risk L SD. Determine change cost and impact L SE. Schedule and conduct change management meetings L SF. Authorize and approve change S LG. Notify affected clients of change timing and impact L SH. Implement change L SI. Verify change met objectives and no negative impacts L SJ. Validate & Report results of change S LK. Perform quality control S LXII. Security A. Establish security requirements & rights S LB. Maintain physical security of assets S LC. Conduct periodic security checks per requirements S LD. Report security violations & weaknesses identified L SE. Resolve security violations L SXIII. Training and Knowledge Transfer A. Plan and Execute Training L SB. Provide Training Materials L SC. Knowledge Transfer L SXIV. DocumentationA. Provide user documentation L SB. Provide technical documentation L SC. Provide operations documentation L SD. Provide training documentation L S

3.1.11 Response Guideline: The offeror’s response to 3.1.11 must describe acceptance of the roles and responsibilities as presented in this section or must clearly identify any deviation and describe why a modification is deemed appropriate.

The offeror must describe how they will incorporate SOS staff into the project team in such a way as to participate in all phases of design, development, and implementation and must describe the responsibilities of both the offeror and SOS in order for this to be achieved.

The offeror must describe how they intend to mentor SOS development staff. The offeror should cite references where the offeror was required to perform in a similar fashion, and must describe the responsibilities of both the offeror and SOS in order for this to be achieved.

The offeror must describe their experiences of working with an independent verification and validation company or similar situation including examples of how the offeror resolved perceived issues.

3.1.12 Development Phases . SOS suggests that the offeror develop and implement SIMS in two phases. As such we have structured this RFP and the core requirements as they would fall into the suggested two phase development structure. If offeror chooses a different deployment schedule, they must incorporate every element included below into the new structure and must provide a detailed basis for the proposed change in development schedule when responding to the RFP.


The two phase approach will be structured by offeror to build the core infrastructure and processing components first, and expand processing types in phase two. The first phase will include all hardware, software, and primary workflows (including interfaces). The second phase will build upon the first by adding additional types of activities, form types, and requests and thus will require that the system handle all the additional types (including new or updated interfaces). SOS performed priority analysis on these work units and has placed critical items in the first phase in order to provide the best service to our customers as soon as possible. Refer to the Input Forms Appendix posted with this RFP for a detailed listing of request item types, within development phase, and the Components Appendix posted with this RFP for a listing of system components and development phases.

Each phased grouping of work will have a complete life cycle of its own, including design, development, pilot, implementation, warranty, and acceptance.

Pilot – Each development phase will have full testing cycles, including a pilot phase. Pilot must include converted data and must exercise the entire application including stress testing, and both inbound and outbound interfaces.

Support – Offeror will support all phases of delivery, including all life cycle tasks. This includes supporting the whole of phase one while developing and deploying phase two.

Hardware/Software – The offeror must ensure that all hardware, software, devices, and network connectivity are in place and operational for system test, pilot, acceptance test and production.

Implementation – Offeror must provide an estimated implementation plan as part of their response to this RFP which includes the transition from legacy business processing to SIMS in phase one and the transition from legacy systems in following phases.

Warranty - Phase one warranty must continue throughout the entirety of phase two and must conclude with the warranty period of the contract as a whole.

Acceptance – Offeror must submit acceptance requests for formalized acceptance by SOS at various points in the project including development phase acceptance; final system acceptance; and warranty period acceptance. SOS will grant acceptance according to mutually agreed upon (SOS and selected offeror) acceptance criteria and may withhold funds until acceptance is granted.

Legacy Systems – Offeror must plan for and assist SOS in the process of controlled retirement of legacy systems as they are taken off line after implementation.

Acceptable implementation timelines must be developed by the selected offeror, taking current business processes into account, and must be approved by the SOS project manager. For example, cutover must be at processing month end to allow for accounting and processing reconciliations and the following time periods contain workloads that would make implementation less favorable:

The month of September each year The month of April each year The first quarter of each year in odd years (2009, 2011, etc.) Sixty days prior to an election (primary or general) in even years (2010, 2012, etc.) Fiscal year end – June 15 through July each year The 15th day of each month The last day of any candidate filing period

Offeror must include estimated project plan timelines for each phase of the project when responding to this RFP. Within one month of contract signing the selected offeror will be expected to submit finalized delivery dates and resource allocations related to the implementation of the SIMS solution for this RFP for SOS approval.


3.1.12 Response Guideline: The offeror must state if they will or will not follow the suggested two phase development structure posed in the RFP. In addition, offeror must describe their proposed approach for delivery of the system as described in this RFP.

The offeror must provide estimated project plan timelines and resource allocations for each phase of the project and demonstrate their abilities to manage the process and all aspects (phases) of development. The offeror must describe their experiences and give examples of delivering systems of this scope and size.

3.2 SYSTEM REQUIREMENTS

SOS has expectations that the system as a whole will be an example of good design and development principles. The system must be table driven and highly configurable in order to significantly reduce the need for programming staff to make adjustments to the system to meet daily business processing needs. SOS has conducted a preliminary code table analysis which will be made available to the offeror to expedite this portion of business analysis.

During business process analysis meetings the SIMS project team identified a desired business flow. These flows have been categorized into three areas – Processing, Administration, and Analysis. Each of these business units is described at a high level here and these concepts are reflected in the requirements matrix included with this RFP. The needs and concepts described here must be addressed by the proposed system. Any differences in terminology or business processing concepts used by the proposed system must be described by offeror and mapped back to the information provided in this RFP.

This section describes the conceptual business model used to develop this RFP and associated system requirements matrix and is organized in four sections:

3.2.1 – Processing – describes the business processes that are expected to be performed related to incoming document processing within the system.

3.2.2 – Administration – describes the business processes that are expected to be performed related to administration functionality within the system.

3.2.3 – Analysis – describes the business processes that are expected to be performed related to analysis functionality within the system.

3.2.4 – System Business Requirements – describes the requirements; the matrix included with this RFP and provides instructions to the offeror on how to respond to the matrix.

3.2.1 Processing. Processing includes the ability to process, account for, image, reconcile, validate, monitor, maintain, and report on customer requests for services and associated payments. Processing can be generally broken down into four steps: Receipt; Image; Compliance; and Notify.

Key terminology that will be helpful in understanding the narrative that follows are described in the referenced terminology document posted with this RFP and are briefly described here. These terms pertain to customer requests and payments for SOS services that are processed centrally.

Batch : A batch is a logical grouping of incoming paper, used to manage work for a receipting clerk. Each batch must have reconciliation points to ensure financial, document and page count, sub-batch, and labeling accuracy. A batch will contain at least one and frequently multiple sub-batches.

Sub-batch : A sub-batch consists of one logical grouping of events. A sub batch may contain any number of pages and may contain multiple event types. Typically a sub-batch will contain a group of pages that were linked together upon receipt –for example, pages in an envelope, fax transmission or those provided by a walk in customer. The sub-batch also includes payments which are applied to the contents of the sub-batch.

Event : An event is a payment or a group of one or more items related to a specific business matter. For example, an event might encompass a filing request form, and associated supporting documents.

Transaction : A transaction is an individual work item. For example, the event above would have two


transactions – one for the request form, and one for the supporting document. The system will associate an identification number to each work item.

Document : A transaction is initiated by a document. A document may be in paper form or an image received in electronic format. For example, a document might be a personal check; a request form; a faxed support document; an invoice statement; etc.

Page : A document consists of one or more pages of information.

SOS has developed a concept for processing and managing the workload. The workflow is based on significant investment of time and effort into business process redesign. Alternate workflows will be considered by SOS, but the offeror must map any other suggestion back to the original workflow to ensure that all needs are met. The goal is to have an application that uses granular security to control all aspects of access, visibility and processing. The application will have online windows that display all required and necessary information with drill down capabilities, and a flexible matrix navigation structure. Windows will facilitate the user experience by performing many tasks automatically. The remaining work performed by the user should be tasks that the system is not well suited to process. The following diagram provides a visual overview of the concept:


ReceiptThe receipting user enters high level information for each transaction. The transaction will be contained in an event, sub batch, and batch. Each batch is validated, labeled, and reconciled and then closed. The batch is then passed to the imaging team.

ImageThe imaging user reconciles the receipting counts and scans images of pertinent documents. Redaction occurs either by the system or manually by the user. User resolves any reconciliation issues and then files the hardcopy batch files. The request events/transactions are then released to business and type driven compliance work queues.


Images may also interface into the system from related systems (online, etc.) or may be entered into the system at later points in the processing cycle. Changes made to documents that have been imaged are recorded as such. Images can be systematically enhanced to improve readability as needed.

Compliance Authorized compliance users access work queues and process each transaction using data and images entered in the previous steps. Additional form-specific information is entered within system guidelines and the transaction is accepted or rejected and recorded as such. The system is expected to facilitate the compliance work by alerting the user to specific conditions, validating contents, preventing the user from processing items in such a way as to violate business rules, and tracking and balancing underpay and overpay amounts. The system also allows for exception processing outside of normal business rules which may require management approvals, documentation, and reason codes.

NotifyAs events are processed various notification items are generated. These items can be sent in various formats and the system provides items needed for each method of notice (fax cover page, email objects, labels). Notification content and format are controlled by customer data (preference for electronic communication, etc.) within the system and the work item to which the correspondence applies. Correspondence is auto-generated using pre- defined templates that reflect processing results. Some correspondence will be imaged and stored within the system (certificates, etc.). Correspondence can also be generated manually at various points throughout the process when a user needs to communicate with the customer. Notifications can be regenerated as needed. All notifications are stored as part of the customer transaction record.

In addition to the processes included in the system, offeror is expected to work closely with SOS to develop procedures for manual processes used to provide information to SIMS or to finish processing information from SIMS.


State of Montana Laws and RulesThe application must adhere to Administrative Rules of Montana (ARM) Title 44, Montana Code Annotated (MCA) and the Federal Food Security Act of 1985 (Farm Bill). Specific items listed below:

MCA CODES:1-5-4021-5-4051-5-4081-5-4091-5-602 to 6101-11-3012-4-311 to 3132-6-1012-6-1032-6-1112-6-2012-6-2022-6-2042-6-2122-6-2132-6-4052-15-4012-15-4057-2-41017-6-15397-6-15407-6-15507-13-22047-13-22147-13-22157-13-23417-13-23427-13-23517-13-25017-15-21077-15-210813-10-201 to 20513-10-20813-10-21113-10-30313-10-32513-10-32713-10-40413-10-40513-10-501 to 50413-10-60113-14-112 to 11413-16-21113-25-101

15-31-52315-31-52415-31-55217-1-10217-2-10217-2-10417-2-10517-2-10917-2-11017-2-30417-6-10518-7-10118-7-10418-7-10718-7-30219-18-10220-7-60430-9A-30130-9A-30230-9A-30730-9A-42030-9A-501 to 50430-9A-50630-9A-50930-9A-510 to 51630-9A-518 to 52030-9A-522 to 52630-13-202 to 20430-13-206 to 21230-13-21430-13-21830-13-22130-13-310 to 31330-13-31530-13-31832-1-10732-1-30132-1-37132-1-100332-3-30132-3-30332-3-322

32-3-32332-4-201 to 20332-4-20533-3-201 to 20333-3-60133-4-20333-4-20433-28-10535-1-216 to 21935-1-22135-1-22935-1-23035-1-23135-1-23235-1-23535-1-308 to 31135-1-313 to 31635-1-81335-1-81435-1-81635-1-93135-1-93335-1-93435-1-94435-1-102835-1-102935-1-103135-1-103835-1-103935-1-110435-1-130835-1-130935-1-131135-1-131235-2-21335-2-21435-2-22535-2-22635-2-22735-2-23235-2-30535-2-30635-2-30735-2-415

35-2-43935-2-60835-2-60935-2-61135-2-61335-2-72035-2-72135-2-72235-2-72335-2-72435-2-82235-2-82335-2-82635-2-83135-2-83235-2-83335-2-90435-3-20135-3-20235-3-20335-3-206 to 20935-4-11035-4-11135-4-20535-4-20635-4-20735-4-20935-4-31235-4-41135-4-50135-4-50235-4-50335-5-10335-5-20135-5-20235-5-20335-6-10235-6-10335-6-10435-8-10335-8-10435-8-10835-8-20135-8-20235-8-20335-8-20435-8-20535-8-207

35-8-20835-8-20935-8-21035-8-21535-8-21635-8-41135-8-80335-8-81235-8-90135-8-90635-8-91135-8-91235-8-100335-8-100735-8-100935-8-101035-8-101135-8-101235-8-101435-8-120135-8-120235-8-121035-8-130135-8-130235-9-10235-9-10335-9-30235-9-40135-9-40235-10-70135-10-70335-12-50535-12-50635-12-60135-12-60235-12-60335-12-60435-12-60635-12-61035-12-61135-12-61235-12-61335-12-61535-12-62035-12-1302 to 130635-15-20135-15-20435-15-205

35-15-21135-15-30535-15-50135-15-50235-15-50435-16-10135-16-20235-16-20435-16-31535-17-20235-17-20335-17-50235-17-50435-18-10735-18-20135-18-20335-18-20435-18-20535-18-20635-18-40135-18-40235-18-40435-18-50135-19-10535-19-30135-19-30235-19-30335-19-31335-19-31535-20-10340-5-24861-12-30369-14-50169-14-50969-14-51169-14-51269-14-55171-3-12571-3-203 to 20671-3-71375-6-30576-15-21376-15-21476-15-80176-15-80376-15-80976-16-20476-16-205

76-16-20676-16-21180-4-40680-8-21082-1-10485-6-101


ARM Codes:

1.2.1041.2.4221.2.4232.4.2012.4.20244.1.10144.2.20344.5.11144.5.11444.5.11544.5.11644.5.11744.5.11844.5.11944.5.12044.5.12144.5.14144.5.20144.6.10444.6.10444.6.10844.6.10944.6.110

44.6.11144.6.11244.6.11344.6.20144.6.20244.6.20344.14.10144.14.10244.14.30144.14.30244.14.30344.14.30444.14.30544.14.30644.14.30744.14.30844.14.30944.14.31044.14.31144.14.31244.15.10144.15.10244.15.10344.15.105

UCC-Federal Regulations:

205.103205.104205.105205.106205.107205.202205.205205.206205.207205.208205.209

Senate Bill:

413

Service of Process:

25-20-Part II Rule 4D

Title 2, Title 30, Title 13, 35 MCA

3.2.1 Response Guideline: If the offeror is suggesting an alteration to processing workflow, the offeror must present the basis for the change together with a refined plan concerning its vision for the alternative workflow ensuring that all aspects of this section have been identified and that all needs are met. If the offeror will adhere to the processing workflow described in this section, the offeror must state they will comply.

The offeror must describe how they would work with SOS to develop procedures for manual processes that are used to provide information to SIMS or to finish processing information from SIMS.

The offeror must describe their experience in working with customers concerning conceptual designs and how they worked together with the customer in order to understand and refine the concepts and transform them into detailed designs and ultimately a successful application.

The offeror must describe how they undergo a development effort and what means they would utilize to ensure that the system they intend to deliver is well designed in terms of flexibility, reuseability and reliability.

The offeror must describe how they view reliability and describe past experiences in developing systems which operate without error and within performance boundaries.


3.2.2 Administration. The SIMS functional area that allows authorized end-users to manage the system from a business perspective. For example, key management areas include customer requests; customer accounts; accounting; data and image adjustments; control tables; system security; and retention. Flexible reporting capabilities and an audit trail must be associated with each tracking area.

Customer Request Tracking Area – track accepted filing and order transaction history in a hierarchical manner:

o master levelo primary level (original filings or orders)o secondary level (filing amendments or order continuations)

Customer Account Tracking Area:o Credit Slip Account – track credit slip activity when a slip is issued, submitted as form of

payment, or replaced; a refund is generated; and/or a grace period is extendedo Ending Balance Billing (EBB) Account - track, calculate, and assess billable order task fees that

are “indirectly” requested by State and local government entitieso Subscription Account – track and analyze subscription information and generate renewal

noticeso Dishonored Payment Account - track dishonored payment transactions, associated replacement

payments, and/or reversal and bad debt write-off activityo Invoice Account - track billable amounts and associated payment activity within billing period;

periodically generate invoice statements- State and Local Government (SLG) billable orders (recurring accounts)- non-SLG billable orders and underpaid filings (one-time accounts)- dishonored payment amounts due (one-time accounts)

Accounting Tracking Area - SIMS is foundationally an accounting system, with filing and order processing functionality “hooked on” to that foundation. The AU accounting area encompasses the following tracking areas at a minimum:

o Batch and Sub-batcho Items Sold and Fees Dueo Amounts Collectedo Amounts Depositedo Pending Interunit Journals (IUJs)o Reconciliationso SABHRS PeopleSoft Financial Entries

Data and Image Adjustments Tracking Area – provide options to update data and images:o Apply mass updates to standardize datao Update filing entity status or associated informationo Annotate, add, modify, and redact imageso Reverse and reprocess erroneous data and imageso Update data and images to reflect uncollectible dishonored paymentso Adjust accounting information

Control Table Tracking Area – track control tables and parameters. System Security Tracking Area - track end-user roles and permissions. Retention Tracking Area - track, perform, and report on retention review and transfer processes and

retention migration and refresh processes system-wide:o Datao Metadatao Imageso Paper

3.2.2 Response Guideline: The offeror must describe their understanding of the Administration activities that must be accommodated by the system as described here and as defined by the system requirements matrix.

If the offeror is suggesting an alteration to administrative functionality, the offeror must present the basis for the change together with a refined plan concerning its vision for the alternative functionality ensuring that all aspects of this section have been identified and that all needs are met. If the offeror will adhere to the administrative functionality described in this section, the offeror must convey acceptance in their response to this section.

3.2.3 Analysis. Analysis is the area used to manage the work and performance of the office based on data, measures, counts and metrics produced by the system. This area also includes those functions where the system communicates with external businesses and their systems in order to transmit data, report on activity, and monitor the health and performance of these activities. Primary analysis activities include reports, extracts, queries, interfaces and the review of the integrity of the data within the system and that data being passed to and from related systems.

The goal is to have analysis functionality that is well designed. This means that flexibility and reusability are taken into account in the design process, not as an afterthought. The system must be able to generate data for parameter driven time frames and values and we want to be able to output data in numerous formats using multiple methods. We also want to ensure that our systems and tools are operating without error and within performance boundaries.

The data provided by the system should be as comprehensive as the user desires, with options for summary or detail level output with automatically calculated fields, counts, and totals. The purpose of this system is to reduce the need for staff to perform redundant tasks that are easily accomplished by a system.

3.2.3.1 Interfaces. The Secretary of State has critical business processes that interact with other systems. The expectation is that the offeror will perform full life cycle development activities for all interfaces needed for the system to meet the requirements defined in this RFP. Changes in SIMS to adjust to changes in the systems with which it communicates or shares data shall be the offeror's responsibility until the detail design is accepted for the phase in which the interface resides.

SIMS must interface with the following external entities and must update appropriate databases, when applicable starting with the first pilot phase continuing through final acceptance and warranty.

The offeror must work with SOS employees during a forms redesign process that will ensure that all paper forms can be generated from SIMS and that the forms align with and contain format, content, and numbering requirements used with the SIMS system and input windows to ensure that pertinent off-line processes interface smoothly with SIMS automated processing requirements.

Integration with external sources is a vital part of this system. Any data sent or received electronically from any source for inclusion in SIMS during each phase must meet data element specifications and file layouts required by SIMS. The offeror will work with external source agencies to develop file formats and testing processes that work for both parties to ensure that files sent and received from other sources are in the proper formats. This should ensure that no data integrity exceptions result from an upload of a file to the SIMS database or image repository. When exceptions do occur, SIMS must have an alert, error, and communication processes that provide detailed information to both parties so the error can very quickly be resolved.

The offeror must work with SOS employees during each phase to ensure that all paper item request forms comply with SIMS format, content, and numbering requirements, when the related item information is input to SIMS, and to ensure that pertinent off-line processes interface smoothly with SIMS automated processing requirements.

Any inputs received electronically from any source for inclusion in SIMS during both phases must meet data element specifications and file layouts required by SIMS. The offeror will ensure that files received from other sources are in the proper formats so that no data integrity exceptions result from an upload of a file to the SIMS database or image repository.

3.2.3.2 Department of Administration Information Technology Services Division (ITSD). SummitNet: SIMS must operate on the State’s SummitNet network architecture. Refer to section 2.6 for details on the State network.

DOA FileNet:o SIMS Image Repository: Presently SOS utilizes image storage on the State’s FileNet system.

We expect to have a system that is tightly integrated with real time interaction with the proposed imaging repository.

DOA ITSD Job Scheduler:o Batch Job Scheduler: Presently SOS utilizes mainframe and mid tier job schedulers for any

regularly scheduled application jobs. Some examples of those job types are for fulfillment of customer orders, data movement, status changes, backups and other similar functions.

DOA SABHRS PeopleSoft Financials System:o PeopleSoft Financials Accounting Entries: SIMS will interface with the State’s enterprise

accounting system, the PeopleSoft Financials application, and combined SIMS accounting entries will update PeopleSoft accounts.

o PeopleSoft Financials IUJ Report: SIMS will interface with the PeopleSoft Financials application and update the SIMS IUJ tracking area with pertinent IUJ information. .

o This interface must meet SABHRS specifications and allow for minor modifications as needed for upgrades to the SABHRS system.

o The information for the SABHRS Interface was downloaded to the SOS web site at the link locations below. This information was taken from the MINE (Montana Information Network for Employees) and is current as of May 1, 2008. It is the responsibility of the offeror to download these documents and incorporate them as part of the RFP as if SOS included these documents in paper form. Of the eleven documents concerning the SABHRS interface, we are including the six that apply to our business functionality below. The document name clarifies the nature of the document. In order to access these documents, the offeror will need a connection to the internet together with Microsoft Internet Explorer or otherwise compatible browser and Microsoft Word or otherwise compatible document reader in order to read the documents.

http://sos.mt.gov/BSB/BSSI/Data_Transfer_Procedure-1[1].doc http://sos.mt.gov/BSB/BSSI/IN_AR_Item_Load.doc http://sos.mt.gov/BSB/BSSI/IN_Deposit_Collection_Load.doc http://sos.mt.gov/BSB/BSSI/IN_General_Ledger_Load.doc http://sos.mt.gov/BSB/BSSI/OUT_Daily_General_Ledger_Transactions.doc http://sos.mt.gov/BSB/BSSI/OUT_General_Ledger_Balances.doc

o It is the responsibility of the offeror to contact the RFP single point of contact if the documents are unclear, not downloadable, or otherwise require clarification.

DOA SummitNet:o Data Communications: SIMS must interface with the State’s SummitNet network architecture.

Refer to Components Appendix posted with this RFP for information regarding SummitNet. DOA Treasury:

o State Treasury Deposits: SOS interacts with the State Treasury office on a daily basis to make physical (manual) deposits of cash and checks.

3.2.3.3 Non ITSD interface Areas.

Express Services:o Express Shipping Accounts – SOS customers can request to have items processed and then

shipped to them using an express mail service. SOS envisions a real time interface to those providers who have the capability for online verification of account numbers.

Internet Services:o Completed Transactions – Lien–Related Accounting, Filing and Order Informationo Deposits – Lien-Related Depositso Farm Bill Informationo Pending Imaging – Lien-Related Orders

http://sos.mt.gov/BSB/BSSI/OUT_General_Ledger_Balances.doc

http://sos.mt.gov/BSB/BSSI/OUT_Daily_General_Ledger_Transactions.doc

http://sos.mt.gov/BSB/BSSI/IN_General_Ledger_Load.doc%20

http://sos.mt.gov/BSB/BSSI/IN_Deposit_Collection_Load.doc

http://sos.mt.gov/BSB/BSSI/IN_AR_Item_Load.doc

http://sos.mt.gov/BSB/BSSI/Data_Transfer_Procedure-1%5B1%5D.doc%20%20%0D%20

o Public Access to Images Via Interneto Registered User Accounts: Customers can choose to pay for items with an Internet Service

account. When payment is made with an account, SIMS must automatically interface with the account during the receipting step. If the input form’s account number and Submitted By entity are valid then SIMS must flag the trust account payment transaction as accepted and update the Internet Services account activity and balance accordingly.

o Electronic Payment Option : SOS is currently working with the eGovernment portal contractor to develop online forms and payment for the most heavily used forms by our customers. SIMS must send and receive requests for services and payment to and from the eGovernment portal.

o Additional interaction with the eGovernment Service provider is defined in the requirements matrix posted with this RFP. For a complete listing of business services provided by the eGovernment service provider please reference http://www.mt.gov/services/business.asp

SOS Legacy Systems:o Legacy Information – Lien-Related Accounting, Filing Information, OPPEN (UCCs) and

Quickbooks SOS Website All:

o Pending Receipting – Fillable Forms: fillable forms are currently available on the SOS website. In addition, the office may post information that will be useful to customers on this web site. In particular, the fillable forms presented in a format which customers can complete off line must be redesigned to have a similar look, feel and format as the new system and any online forms available to our customers.

USPO:o Zip Codes: The United State Postal Office provides updates to postal codes. SIMS must be

able to import these codes for use by our end users. SOS System EGSU:

o Oracle Candidate Filing System: The candidate filing system will continue to be the primary system used to manage and report on candidate activity within the State of Montana. The SIMS system will be responsible for the initial processing of candidate request items which includes the collection of money and a process through workflow that will result in the request information being interfaced into the Candidate Filing System.

SOS Website ARNU:o Pending Receipting – Billable Orders: The SIMS system will be the primary input source for all

orders processes by ARNU. These orders will create work items that will be filled by the staff with completion information, counts and status recorded in SIMS. The system will have an invoicing component which will allow billable items to be recorded, charged, invoiced and paid for the customer receiving services.

3.2.3 Response Guideline: The offeror must describe their understanding of our desire for parameter driven flexible reporting and data analysis tools and describe and present examples of systems that offeror has previously developed with this type of functionality.

The selected offeror must plan, schedule and outline a complete forms redesign process as part of this project. The offeror must provide detailed descriptions of how they will conduct this effort and describe their experience in migrating large volumes of input forms from legacy formats and processes into a new system and environment.

The offeror must describe their experience with external business partners on complex interface processes; with the State of Montana, and particularly any of the interfaces listed above should be highlighted; and with the business functions and technologies described by the interface areas in this section.

3.2.4 System Business Requirements (SBR ). Functional requirements for SIMS were developed by SOS project staff through interviews, surveys, meetings and research efforts, and the results combined to form the system business requirements (SBR). The SBR embodies a conceptual system design, which meets both the business requirements and the objectives of the general system requirements.

The business requirements define key system concepts and, set the scope of the project. The following sections describe one way the system could function, not the only way. Offeror may propose a different solution, but is required to map the proposed system to the concept presented in this RFP.

The system requirements matrix is posted to the State Procurement Bureau’s website at http://gsd.mt.gov/osbs/Results.asp?CategoryID=14.

3.2.4 Response Guideline: SOS would like to have an idea of how much of the proposed system is going to be used from an existing code base and how much of the system will be developed from the ground up. Explanations of how your system meets or will be built or modified to meet our needs will be very helpful. Additionally, explanations of the areas where your system will not meet a requirement will also be helpful. The offeror must acknowledge each requirement in the system requirements matrix making a mark with the number one (1) on the column that shows their ability to comply with each requirement. Offeror options are: 1. Propose existing system that meets the requirement 2. Propose existing system that will meet the requirement with a modification to a component that already exists 3. Propose a solution that does not meet the requirement 4. Propose a solution to build functionality that will meet the requirement 5. Other solution. Offeror must describe other solution.

Offeror is strongly encouraged to provide additional information on its ability to meet the requirements paying particular attention to those that are not in a meet (option #1) or build (option #4) status. A listing of requirement comments by number will assist SOS in understanding offeror’s proposed solution abilities to meet our specific needs.

If the offeror’s solution does not meet a requirement (option #3) or must be modified or built to meet a requirement (option #2 and #4), or if the offeror states that their solution meets a requirement (option #1) but later it is determined that it does not, then the selected offeror must modify their solution in order to meet the requirement at no additional cost to SOS.

If SOS finds that offeror has significantly misrepresented their proposed system by indicating that their system meets (option #1) many of the requirements when in fact their system does not meet those requirements, then SOS reserves the right to extend the project plan timeline and associated invoice payment dates to allow for additional development time and may reassess the impact the erroneous responses had on the RFP evaluation and selection process.

3.3 PROJECT INFRASTRUCTURE

3.3.1 System and Architecture Standards. The State of Montana and SOS have IT standards that the proposed solution must interface with, utilize, or provide. All software, including database management systems, software development tools, personal computer operating systems, personal computer applications, network operating systems, network transport software, and other software recommended by the offeror is mandated to be within State supported software standards as listed in the Components Appendix posted to the website with this RFP. Proposals will be evaluated by SOS for compatibility with and adherence to current State software standards. Responses that do not adhere to State software standards will receive a failed rating and will not be considered further.

The offeror shall provide detailed technical specifications for devices and all other hardware required as part of the proposal. No alpha or beta test hardware will be accepted by SOS. Offeror must demonstrate analytically that the equipment to be used meets the capacity and performance requirements of the system. If, in the course of this contract, capacity or performance is found to fall short of operational requirements defined in this RFP, the offeror must modify the system to meet these requirements at the offeror's expense. Refer to

Components Appendix posted to the website with this RFP for information regarding hardware the State has available for integration.

Network wiring within SOS facilities will be provided by SOS. The proposal must specify any wiring requirements.

Infrastructure Components

3.3.1.1 Operating System. The selected offeror must: Recommend all needed operating systems for any machine or device interacting with the system. Assist with the installation and configuration of all operating systems for any machine or device

interacting with the system. Recommend upgrades on and enhancements to operating systems for any machine or device

interacting with the system for duration of the contract. Assist with upgrade activities of operating systems for any device interacting with the system over

lifespan of contract.

3.3.1 . 2 Database . Provide an n-tier, supporting both “rich client” and integrated eGovernment portal web functionality and utilizing contemporary relational database technology. The database technology must be Oracle or Microsoft SQL. The selected offeror must:

Recommend all needed database applications for the system. Assist with the installation and configuration of all database applications utilized in any operation of the

system. Provide status and metric reporting on performance of database. Recommend upgrades and enhancements on database application over lifespan of contract. Assist with upgrade activities of database platform over lifespan of contract. Provide the capability to analyze the database for any errors in data, indexing, and/or relationships.

3.3.1.3 Front-End . The offeror is strongly encouraged to use the Microsoft .NET framework for the front end development of SIMS. The SOS office has a limited number of IT staff, and has other applications using a .NET front end. We would like to focus our training efforts and skill expertise on a small set of tools. Significant preference will be given for a .NET front end, but other options will also be considered. Responses using something other than .NET can receive no more than a good rating (see section 6.0 for description.)

The offeror shall make good use of automated analysis and design tools, high-level programming languages, development and testing aids, and documentation aids.

Unless specifically agreed by SOS, all software delivered to SOS shall be the most recent production version supplied by the manufacturer prior to the acceptance of the detail design. All updates of commercial software used in the system will be obtained by SOS and installed by the offeror, except by documented mutual agreement of SOS and the offeror.

SOS expects the selected offeror to recommend all needed software for the system and business processing. They will be expected to actively assist with the installation and configurations of all software utilized in any operation of the system; and recommend upgrades and enhancements on software devices over lifespan of contract; and assist. Assist with upgrade activities on software over lifespan of contract.

3.3.1.4 Development Tools. In the offeror’s response to the RFP, offeror must list the tools planned for the project, a description of their use, and the maintenance requirements. The tools must include at a minimum:

Integrated Development Environment consisting of:o Source Code Editoro Compiler and/or Interpreter

o Build Automation Toolso Debuggero Class Browsero Object Inspectoro Version Control System

Data Dictionary Screen Designer Report Writer Query Facility Message Facility User Help Facility

3.3.1.5 Hardware. The selected offeror must: Recommend all needed hardware for the system, including all peripheral devices (monitors, CPU,

scanners, bar code readers, and printers used by SIMS users, as well as other peripherals which might be offered) needed for business processing;

Assist with the installation and configuration of all system hardware and devices utilized in any operation of the system;

Provide a mechanism for status and metric reporting on performance of hardware; Recommend upgrades and enhancements on hardware and peripheral devices during the lifespan of

this contract; and Assist with upgrade activities on hardware over lifespan of contract.

3.3.1 Response Guideline: The offeror must describe its recommendation for SOS to obtain, install, and maintain operating systems, databases, devices, and any other proposed hardware and/or software for the life of the contract, including optional extensions.

Offeror must describe the reliability, serviceability, integration capabilities, ability to scale and expected lifetime of proposed devices, hardware, or software.

3.3.2 Custom Software . All custom software developed by the offeror and used in this system shall be licensed to SOS, including specifications, source code, object code, and documentation. This license shall include the right of SOS or its providers to use such software in this or any other SOS system for an indefinite period and in unlimited quantities. During this contract, the offeror will maintain and upgrade custom software as needed to operate this system. SOS shall be licensed to modify all custom software provided by the offeror for this system for SOS use which is outside the scope or duration of this contract.

If the offeror proposes an existing system as the basis for SIMS, and new versions of the software, components, or tools are release prior to the end of the design phase for each development phase, SOS has the option to require the latest version of these tools to be used for development of all phases that have not passed through detailed design acceptance.

Within two years of final acceptance of the system, if the offeror enhances or corrects custom software used in SIMS for its own use, or for another customer, the offeror must notify the SOS Project Manager of such an update of custom software within 30 days of completion of such update. If SOS chooses to explore the installation of the enhancement, a separate contract will be initiated for integration.

3.3.2 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section. Offeror must fully describe the license structure of the proposed system. Also, describe the ongoing operation of this license structure including at a minimum the degree to which the system is customizable by SOS. If offeror is proposing an existing system or COTS system, describe the process that will be used to release new versions and/or updates to the system and describe if those are mandatory or optional. Describe the management of the license structure and advantages and potential risks of that

structure to SOS. Provide details on offeror’s experience with the proposed license structure. Any aspects of price that may be related to or impacted by license structure must be included in the price sheet described in section 5.

3.3.3 Offeror Provided Items. In addition to the application requirements stated elsewhere in this RFP, the offeror will be asked to provide the following items as part of the cost of the proposed solution.

3.3.3.1 Included Items. Offeror provided items include, but are not limited to: Development tools for offeror staff Contracted services Training manuals Operator manuals Technical manuals Disaster and recovery documentation Complete commented source code Complete system functionality Other special licenses (e.g. APIs, development libraries, modules)

3.3.3.2 Listing of Required Components. The offeror must provide a complete list of the State hardware, operating systems, web server software, browser software, programming languages, development tools, libraries, management tools, browsers, network infrastructure and any other components that are required for the proposed solution to be successfully installed and maintained.

3.3.3 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section and describe any additional items not presented above.

3.3.4 State Provided Items. The State acknowledges that there are certain items that it must provide in order to support the successful installation of the proposed solution. These include:

Provide the network infrastructure. The State network will be used to connect the various SOS office locations to the central site hosting the system. Offeror can view the network infrastructure at the following link: http://www.state.mt.us/itsd/techmt/summitnet.asp. Currently, SOS office locations have broadband connection speeds:

o Annex to Mitchell building – one (1) gigabyte fiber single mode by 6/1/2008 - connection to Agriculture’s switch then to Mitchell building so it is also shared.

o RIMD to Mitchell building – 24 megabyte Microwave – connection to the Capitol then to the Mitchell Bldg.

o Capitol to Mitchell building – one (1) gigabyte multimode fiber - connection is shared between three agencies housed in the capitol building.

Provide workstations, printers, and devices for State employees that will be utilizing the proposed solution.

Provide central hardware (i.e. servers, storage etc.). Software and Tools

o Development tools for SOS staffo Infrastructure software (Oracle, MS SQL, Windows Server, etc.)o All database server licenses required for the Development, Test, Training and Production

systemso All FileNet licenseso SSL certificate(s)

3.3.4 Response Guideline: The offeror’s response to 3.3.4 must: Identify a software solution and include whether it is commercial, custom, or a combination thereof. Identify and include manufacturer’s documentation of any commercial software components which are

proposed to be integrated.

http://www.state.mt.us/itsd/techmt/summitnet.asp

Discuss why the software solution is preferred for the SIMS project. Incorporate how the solution meets the software requirements defined herein. Suggest a relational DBMS solution for SIMS and discuss how it will meet the needs stated. Identify all development tools to be utilized in developing and implementing SIMS. Assess the section and describe any deficiencies or concerns regarding its proposed offering to SOS.

3.3.5 Imaging . SOS currently stores imaged records in the MT DOA/ITSD FileNet system and locally on the cluster volumes for the Netware servers. All images are multi page TIFF files and are scanned at 200 and 300 dpi resolutions in black and white. Currently, the primary business units for scanning are Notary, Corporations, and UCC. All images are indexed for automated retrieval.

The current image inventory must be included in conversion by the selected offeror, including data from the controlling data bases. In the SIMS environment, the images themselves are subject to both retention rules within the SIMS system and redaction requirements contained in this RFP.

MT SOS is envisioning creating a paperless processing environment. This means that all paper (as appropriate for business processes), communications, and other submissions can be scanned and appropriately indexed to allow for future retrieval within SIMS.

It is also further envisioned that the images are really considered content and as such other content like word processing documents, e-mails, reports, notifications, request forms, invoice statements, payment documents, support documents, certificates and the like that are any part of any of the business processes for SIMS shall be managed accordingly and are for all purposes considered part of imaging.

3.3.5 Response Guideline: The offeror shall clarify in their response how their proposed system handles these objects in terms consistent with SOS functional business areas.

3.3.6 Conversion Overview . SOS systems support mission critical applications that cannot tolerate outages that are caused by conversion issues. Any disruption during the conversion effort or as a result of the conversion during the term of the contract is not acceptable and will be subject to liquidated damages. Posted to the website with this RFP is a Conversion Appendix with a preliminary conversion plan and information on the analysis that has been conducted to date on this critical project area. The selected offeror must document and implement a transition and conversion plan for the current (SOS) data after conducting a joint SOS/offeror detail analysis of current data and all tasks as outlined in the conversion appendix. Although the format of the conversion plan need not mirror the plan included in this RFP, all aspects of conversion as described in that appendix must be included in the plan created by the selected offeror and approved by the SOS project manager.

The selected offeror must ensure regular business functions are not disrupted by the conversion process and adhere to an agreed upon conversion plan and protocols. The conversion of SOS data requires high accuracy transfer of critical applications with either no interruption or a specifically scheduled interruption of service. The selected offeror must coordinate and assist SOS/ITSD staff with the installation of any special or additional services or equipment that is required for the conversion.

SOS expects to participate in conversion to the extent that we (or our sub-contractors) will provide extracted data from our existing systems to offeror. Offeror must then manipulate, scrub, and otherwise prepare the data and then load the data into the SIMS data structure. Conversion processes must be accepted by the SOS project manager as meeting acceptance criteria prior to progressing with pilot/production implementations.

3.3.6 Response Guideline: In response to this RFP the offeror must describe their level of experience with converting data for large system integration projects and provide examples of conversion experience with accounting data.

The offeror must describe their recommended conversion strategy. The conversion strategy must include an approach for the development and successful execution of a conversion effort that should include at a minimum: Scope of conversion effort Data conversion alternatives Conversion methodology Resources and timelines

The offeror must convey acceptance of the requirements, any referenced appendixes, processes, roles and responsibilities, given in this section.

3.3.7 Retention . The SIMS application must have automated retention functionality that can provide for classification of a record, ability to satisfy the phases of a record for it’s life cycle, and ability for capabilities sufficient to handle a variety of schedules for the ‘record’ in all of it’s existing forms. The SIMS application must manage and track the action for the ‘record’ from creation to maintenance to disposition and allow for both manual and automated alterations of the retention record and provide customizable notifications to the business units prior to destruction.

3.3.7 Response Guideline: The offeror must convey acceptance of the requirements given in this section, and describe their experiences with content like spreadsheets, documents, email, e-docs as it relates to retention. In addition, describe the offeror’s experiences with retention processes on elements at row level data in tables within relational databases.

3.3.8 Redaction . The SIMS application must incorporate appropriate technology to redact certain information from the image after scanning. Automated redaction capabilities can be form based and/or pattern based, and tools must allow users to perform manual redaction as needed. The original layer document must be retained and all layers of the image must be viewable to those with appropriate rights.

3.3.8 Response Guideline: The offeror must convey acceptance of the requirements given in this section, and describe their experiences with redaction and redaction software together with a discussion for an implementation relative to the context of this RFP.

3.3.9 Environments. In order to facilitate the development, test, training, and implementation phases it will be necessary for the offeror to provide four complete system environments. These environments will be hosted at ITSD’s Helena data center. VPN access will be available to offeror project staff as needed.

Updates to end-user systems must be managed from a central location. Preference will be given to the use of the Microsoft .NET framework to perform client updates. Responses using something other than .NET can receive no more than a good rating (see section 6.0 for description.).

3.3.9.1 Development System. To be used by developers to build the code and do initial testing. This environment will be provided by SOS and will be housed within the SOS environment provided by ITSD. The selected offeror must:

Recommend development environment configuration and capacity requirements. Document a complete system architecture plan. Utilize a development database with limited test records.

3.3.9.2 Test System. To be used by developers and end users for testing of code before it goes into production and for testing of the legacy data conversion process. This environment will be provided by SOS and will be housed within the SOS environment provided by ITSD. The selected offeror must:

Document a complete system architecture plan. Recommend test environment configuration and capacity requirements. Utilize a separate test database instance from the development system. Populate this environment with a more robust set of data than the development system

(but does not have to contain a full copy of production data). Utilize a backup and restore system that will facilitate the ability to roll the environment

to a previous state within a reasonable period of time relevant to the amount of data contained in the environment.

3.3.9.3 Training System. To be used by developers and end users for training purposes related to the use, operation, and maintenance of the system. This environment will be provided by SOS and will be housed within the SOS environment provided by ITSD. The selected offeror must:

Document a complete system architecture plan. Recommend Training environment configuration and capacity requirements. Utilize a separate training database instance from the development system. Populate this environment with a more robust set of data than the development system

(but does not have to contain a full copy of production data). Utilize a backup and restore system that will facilitate the ability to roll the environment

to a previous state within a reasonable period of time relevant to the amount of data contained in the environment.

3.3.9.4 Production System. This is the primary system to be used in production. This environment will be provided by SOS and will be housed within the SOS environment provided by ITSD. The selected offeror must:

Document a complete system architecture plan. Recommend production environment configuration and capacity requirements. Utilize more robust network connections than the test and development systems. Recommend hardware that provides for power, hard drive, and other such core

component redundancy. Provide complete backup/restore capabilities.

3.3.9.5 Version Control . The selected offeror must: Utilize an electronic version control system to manage the development efforts being performed on

objects in the system. Notify all affected users that a software version update is required and the time such change will be

administered if the offeror is expecting to make a change during regular SOS operating hours, Use a version control system to manage the modification of source code. Document changes to code in the version control system in addition to ‘in-line’ documentation, although

this may be at a higher or summary level of detail. Administer, test, document, and track all version changes, and to ensure receipt of remotely

administered software version updates. Train SOS staff in the process, procedures and use of the version control process prior to the transfer

of system responsibility to SOS. Offeror must train SOS staff in the process, procedures and use of the version control process prior to

the transfer of system responsibility to SOS.

Version control system must: Allow for check out and check in of objects, with descriptive comments required at each check in. Provide for documentation of which objects or code sets are in each migration or release of the

application within and between the test, training, and production environments.

3.3.9 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section and describe their experience in working within and managing multi-tiered environments. Offeror must describe their experience in code migration management.

3.3.10 Security and Controls. The proposed solution must conform to state statutes and guidelines and the requirements included in this RFP and the reference documents posted on the State of Montana web site.

3.3.10 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section.

3.3.11 System Performance Specification. The State has included performance specifications in the requirements matrix that the offeror’s solution must meet. The offeror should develop a response to performance specifications that displays an understanding of the needs of SOS.

3.3.11 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section. The offeror is encouraged to describe how they would meet or exceed the requirements for performance as well as how they would measure and validate the results.

3.3.12 Backup and Recovery. Backup and disaster recovery are required components in the proposed solution. The offeror must ensure that no information is lost and that the application is capable of restarting in-progress processes.

3.3.12.1 Recovery. The offeror must describe the proposed solution’s ability to recover from events such as a power failure or a system hardware failure. SOS expects the offeror to fully participate in the event of a recovery event regardless of the nature, location or source of the event.

Describe capabilities of recovering data from desktop failure event. Describe capabilities of recovering data from server failure event. Be able to restart desk top processes within five minutes of the restoration of power.

3.3.12.2 Backup. The offeror must describe the proposed solution’s ability to provide backup and disaster recovery capabilities:

Describe capabilities of recovering the system from disaster event. Provide a plan that shows evidence that it has been tested and includes a regular test plan that will be

implemented by the offeror a minimum of twice per year and be coordinated with SOS. The plan must address all recovery aspects of the proposed solution. The plan must be in place during the system test phase of the plan and must be fully and successfully implemented at least once by offeror during system test for any phase. The plan should include but not be limited to:

a. Off-site storage of all software necessary to operate all aspects of the system. Off-site location may be more than 100 miles from Helena and will be provided by SOS.

b. The approximate time it would take to obtain equipment, software, materials, etc. to resume system operations. Offeror must plan, but SOS and ITSD will provide this information based on the Data Center provided.

The offeror will schedule and track successful execution of bi-annual (or more frequent) disaster recovery drills. In the event of a disaster, failure of the offeror components of the disaster recovery procedure to fully restore SIMS to operating condition shall subject the offeror to liquidated damages, regardless of what kind of disaster causes such conditions to occur.

3.3.12 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section.

3.3.13 System Documentation. System documentation must be written and/or revised by offeror to reflect the impact of the development for each phase of SIMS. Offeror must give accurate, updated system documentation to SOS prior to and as a condition of acceptance of each pilot and development phase of the system.

Documentation must be in hard copy and electronic form and must include, but is not limited to: Comprehensive database diagrams or entity relationship diagrams Data dictionary entries covering data domains, tables, and attributes Functional and process decomposition diagrams Data flow diagrams Users’ and procedure manuals for each system unit defined in the requirements matrix Operations production schedules Disaster recovery plan System back up and recovery procedures Action diagrams for all programs Input/output layouts Program source code Copies of test data files and test scripts/criterion

3.3.13 Response Guideline: Offeror’s response to this section must identify and describe documentation for the full system development life cycle and discuss how the documentation will be used by offeror to plan and design SIMS. Offeror must describe how documentation will be used to provide training, disaster recovery, and knowledge transfer services. The offeror is encouraged to provide examples of documentation as appropriate.

3.4 OPERATIONAL SUPPORT REQUIREMENTS

This RFP section contains operational based activities. The offeror must operate SIMS until the final warranty period ends. The offeror must train and mentor SOS staff on all aspects of system operation to ensure that the system can be maintained in good standing by SOS staff. SOS retains the right to assume the operational duties defined under this subsection, in whole or in part, at any time during the operational support period of this contract. However, should SOS decide to assume such duties, sufficient notice, to be negotiated by offeror and SOS, shall be given to the offeror to allow for a smooth exchange of duties.

SOS users must be able to access SIMS each work day from the hours of 8:00 AM through 5:00 PM, Mountain Time. The system must be made available for overtime or weekend processing during peak processing periods.

3.4.1 Issues, Enhancements, and Defects. The offeror will be responsible for tasks relating to operations of the system until the last phase has passed final acceptance. SOS retains the right to assume the operational duties defined under this subsection, in whole or in part, at any time during the operational support period of this contract. However, should SOS decide to assume such duties, sufficient notice, to be negotiated by offeror and SOS, shall be given to the offeror to allow for a smooth exchange of duties.

SOS and the offeror will work together to define severity classifications, or priorities, of operational support tasks and their associated required resolution time periods. Failure by the offeror to resolve operational support-related events, such as questions, service requests, or system generated exceptions within the agreed upon resolution time period may subject the offeror to liability for liquidated damages.

For evaluation purposes, priorities are defined as follows: 1 = critical system failures2 = high3 = medium4 = low

Offeror must immediately notify the SOS Project Manager of any ‘level one’ issues and provide ongoing status. The offeror must include in their response the correlating response time period they feel is appropriate for each priority level in order to ensure operational support events are resolved within acceptable time lines.

3.4.1.1 Help Desk. The offeror must staff an internal help desk, or dispatcher, for receipt of requests from SIMS end-users during the State’s normal business hours 8:00 AM through 5:00 PM Mountain Time, through the final warranty period. The offeror shall identify in its proposal how it plans to accommodate help desk dispatcher support, and shall provide the number of staff proposed to handle support. At a minimum, offeror must:

Utilize the RightNow application to manage all requests Establish the knowledge base within the RightNow application Process all requests through RightNow Triage incoming requests; elevate candidates for change following change plan Transition the RightNow application to SOS staff at the end of the contract Adhere to the project change management plan for processing of requests

The offeror must utilize the help desk system provided by SOS. Currently the system being used is the RightNow Service package. This system allows for customer self service via a populated knowledge base, and also has commonly available help desk functionality. The offeror must populate and manage the knowledge base until final acceptance of the complete integrated SIMS system. Offeror will be expected to produce bi-weekly help desk statistics which include at a minimum:

Number of new reports Number of reports at various days old Number of closed reports Number of reports by priority Number of reports by type (hardware, software, system) Number of reports by source (user error, training, requirement, design) Number of reports to each technical staff member Trending of number of new and closed reports over time.

The offeror may request the SOS Project Manager to grant an extension beyond the agreed upon resolution time period, and the SOS Project Manager may grant such an extension, provided the offeror has demonstrated due diligence in pursuing diagnosis and correction for the event question, service request, or system generated exception. Resolution within the required time period, or possible extension thereof, does not reduce the offeror's liability for liquidated damages.

3.4.1 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section

3.4.2 Batch Processes. The system must have mechanisms to perform batch processes as needed for the operation and upkeep of the system and data. SIMS must run batch processes on a schedule without manual intervention or observation from users and must have front end functionality that allows authorized end-users to modify batch parameters when desired. Offeror may evaluate the State scheduler tool and use if appropriate for SIMS. 3.4.2 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section and describe its approach to support of tasks in this section.

3.4.3 Production Schedules . Offeror will coordinate with external agencies to record, maintain, and track well-documented production schedules (daily, weekly, monthly, quarterly, etc.) required in order to process SIMS production jobs. Offeror will schedule jobs in such a manner so as to reduce impact on end-users.

3.4.3 Response Guideline: At a minimum, the offeror must convey acceptance of the requirements given in this section and describe its approach to support of tasks in this section.

3.4.4 Batch Processing Monitoring . Offeror shall provide a mechanism to monitor error situations encountered in batch processing, and utilize the software to document error situations. Offeror must immediately notify the SOS Project Manager of any issue and ongoing status.


3.4.5 Special Requests . The offeror must satisfy requests for special SIMS reports or data extracts from the SOS Project Manager. These requests will likely be the result of a legislative or management inquiry into business behavior, counts, or financial calculations that will be used to analyze operations or processing within SOS.


3.4.6 Data Integrity . The selected offeror must: Monitor the SIMS database for detection of “bad” data (invalid data values, etc.) or database overflows,

and the subsequent clean-up of the database. Investigate and correct data integrity problems such as those resulting from conversion, software, data

errors caused by validation/edit issues, or other system or calculation errors. Resolve data integrity problems in a timely manner. Document fully the detection of software data integrity errors, as well as the resolution itself; including

steps taken to ensure the particular data integrity problem will not reoccur.


SECTION 4: OFFEROR QUALIFICATIONS/INFORMATIONAL REQUIREMENTS

4.0 STATE’S RIGHT TO INVESTIGATE AND REJECT

The State may make such investigations as deemed necessary to determine the ability of the offeror to provide the supplies and/or perform the services specified. The State reserves the right to reject any proposal if the evidence submitted by, or investigation of, the offeror fails to satisfy the State that the offeror is properly qualified to carry out the obligations of the contract or is inconsistent with information provided in response to the RFP. This includes the State’s ability to reject the proposal based on negative references.

4.1 OFFEROR QUALIFICATIONS/INFORMATIONAL REQUIREMENTS

In order for the State to determine the capabilities of an offeror to provide the supplies and/or perform the services specified in Section 3 above, the offeror must respond to the following requests for information regarding its ability to meet the State's requirements. THE RESPONSE “(OFFEROR’S NAME)” UNDERSTANDS AND WILL COMPLY IS NOT APPROPRIATE FOR THIS SECTION.

(NOTE: Each item must be thoroughly addressed. Offerors taking exception to any requirements listed in this section may be found non-responsive or be subject to point deductions.)

4.1.1 References. Offeror shall provide a minimum of three references that are using supplies and/or services of the type proposed in this RFP. The references may include state government or universities where the offeror, preferably within the last three years, has successfully completed a contract to design, develop, and implement a large scale image based application system. At a minimum, the offeror shall provide the company name, the location where the supplies and/or services were provided, contact person(s), customer’s telephone number, e-mail address, and a complete description of the service type, and dates the services were provided. These references may be contacted to verify offeror’s ability to perform the contract. The State reserves the right to use any information or additional references deemed necessary to establish the ability of the offeror to perform the conditions of the contract. Negative references may be grounds for proposal disqualification.

4.1.2 Company Profile and Experience. Offeror shall specify how long the individual/company submitting the proposal has been in the business of providing supplies and/or services similar to those requested in this RFP and under what company name. Offeror should provide a complete description of any relevant past projects, including the supply/service type and dates the supplies and/or services were provided.

4.1.3 Method of Providing Services. Offeror shall provide a work plan and the methods to be used that will convincingly demonstrate to the State what the offeror intends to do; the timeframes necessary to accomplish the work; and how the work will be accomplished to meet the contract requirements as more specifically detailed above in Section 3.

4.1.4 Offeror Financial Stability. Offerors shall demonstrate their financial stability to supply, install and support the services specified by: (1) providing financial statements, preferably audited, for the three consecutive years immediately preceding the issuance of this RFP, and (2) providing copies of any quarterly financial statements that have been prepared since the end of the period reported by its most recent annual report.

4.1.5 Local Presence. A local project office maintained in Helena Montana is required for the duration of the contract. A local project office must contain at a minimum the project manager and project office support staff such as administrative assistant and project schedule maintenance analyst. The project manager must be a PMI certified Project Management Professional (PMP).

In addition, “key milestone leads” must be located in the Helena Montana project office during the duration of the milestone that they are responsible for coordinating, monitoring, and allocating resources. Key milestone leads are the people that are assigned to oversee the major sections of the project as defined in the Statement of Work that coincides with the milestones of the holdback table as defined in the contract (section 14.2).

SOS has this requirement because of their past experiences with projects and the difficulty that occurred in trying to coordinate meetings and conduct issue resolution between time zones and the use of teleconferences. Project coordination and issue resolution are more productive if the parties involved can quickly call the meeting (within an hour) and meet face to face. Given the timeframe for the implementation of this project the success will depend on the appropriate parties being able to resolve issues quickly.

4.1.6 Key Personnel. The offeror must provide detailed information about the experience and qualifications of the key staff assigned to this project. This staff information must also include the role and responsibilities, their planned level of effort, and their anticipated duration of involvement with the project. Key staff roles include but is not limited to:

Project Manager Database Administrator Application Development Lead Key Milestone Leads System Engineer Data Conversion Manager Trainer

Resumes must be provided for all key staff and must include name, education, training, technical experience, functional experience, specific dates and names of employers, relevant and related experience, references, past and present projects with dates and responsibilities and any applicable certifications. References must include client name, title, company name, address, telephone number and email address.

The offeror must follow all state standards of conduct and state ethics laws concerning the placement of any staff on the project. Offeror replacement of key staff shall be subject to the approval of the State. Failure to coordinate and gain State approval prior to key staff replacement may be a material breach of contract and therefore subject to contract termination.

4.1.7 Oral Presentation/Product Demonstration. The offeror’s oral presentation will include a review of their proposal by section, and are not to exceed four hours in duration. Prior to the demonstration the offeror must provide SOS with a list of names of all personnel attending the demonstration with corporate position titles, tenure with the corporation, and relationship to the call center project. The presentation will include:

Demonstrate the COTS system as it applies to SOS. This step will be utilized only if all offerors have a system to demonstrate. If only a subset of offerors have a system, the evaluation of those systems would present an advantage to some offerors over others.

The State reserves the right to interview only the two highest scoring offerors, or to interview all offerors within 10% of the highest scoring offeror, or to interview all offerors who are deemed to have a passing score prior to the interview presentation process, at the State’s discretion.

SECTION 5: COST PROPOSAL

5.0 COST PROPOSAL

The budget for this system is unknown at this time as the final amount will be determined by the solutions offered/selected.

Offerors must provide a detailed line-item budget for all phases of the project.

Provide separate cost for system maintenance following the 12-month warranty period. The State reserves the option of choosing contractor provided maintenance (under a separate contract) or provide for these functions in-house. These costs will not be considered as part of the cost evaluation.

5.1 REQUIRED PRICING INFORMATION

The offeror must provide a separate cost sheet that includes a total firm fixed price for the SIMS project and the cost breakdowns as detailed below:

5.1.1 Staff Information. The total number of proposed project full-time equivalent (FTE) and part-time staff costs by position and role. This includes the fully loaded staff rates (inclusive of salary, benefits, and travel related costs) cost rollups by position and role.

5.1.2 Project Management. The amount of project management costs allocated to each of the proposed development phases (include warranty as a phase), and a total for the project as a whole.

5.1.3 Development. The amount of development costs allocated to each of the proposed development phases (include warranty as a phase), and a total for the project as a whole. Describe what services and tasks are included in this section of the cost proposal.

5.1.4 Conversion. The amount of conversion costs allocated to each of the proposed development phases, and a total for the project as a whole.

5.1.5 Testing. The amount of testing costs allocated to each of the proposed development phases, and a total for the project as a whole.

5.1.6 Total Training Costs. This will include all costs associated with training including instructors and materials.

5.1.7 Environment. Non-Services Related Costs. (i.e. hardware, firmware, etc.) This should also include costs for ancillary system upgrades or changes to existing infrastructure required by proposed system.

5.1.8 Help Desk. This will include all costs associated with operating the help desk until all warranty obligations have been met, changed or waived.

5.1.9 Warranty. The amount of warranty costs allocated to each of the proposed development phases (include warranty as a phase), and a total for the project as a whole.

5.1.10 Total Firm Fixed Price. The total project cost of items 5.1.1 through 5.1.9.

5.1.11 Ongoing Service Rates. Include a proposal for contracting services to assist SOS in the maintenance of this system for a 36-month time period following the warranty period. Include hourly rates by role and experience level. Also include a not-to-exceed percentage for services for an additional seven years.

5.1.12 License costs. Include details for any license related costs. This must include all aspects of ownership of the product and any new releases and/or updates to the application.

5.2 PAYMENT SCHEDULE

Payment will be made upon implementation and State approval of: SOS Acceptance of products and services of each milestone as defined in the contract awarded as a

result of this RFP. Final Acceptance (Holdback).

The total firm fixed price includes all items listed in sections 5.1.1 through 5.1.9 and any cost of software and all associated license fees. The offeror will invoice the State for achieved milestones which represent portions of the cost of the total project price upon State acceptance of each milestone. The holdback will be tendered on a monthly basis during the 12 month warranty period.

SECTION 6: EVALUATION PROCESS

6.0 BASIS OF EVALUATION

The evaluator/evaluation committee will review and evaluate the offers according to the following criteria based on a total number of 1,500 points.

The Scope of Project, References, Company Profile and Experience, Method of Providing Services, Local Presence, Key Personnel, Oral Presentation/Product Demonstration, and Bonus Points portions of the offer will be evaluated based on the following Scoring Guide. The Financial Stability portion of the offer will be evaluated on a pass/fail basis, with any offeror receiving a "fail" eliminated from further consideration. The Cost Proposal will be evaluated based on the formula set forth below.

Any response that fails to achieve a passing score per the requirements of Section 2.3.5 will be eliminated from further consideration. A "fail" for any individual evaluation criterion may result in proposal disqualification at the discretion of the procurement officer.

SCORING GUIDE

In awarding points to the evaluation criteria, the evaluator/evaluation committee will consider the following guidelines:

Superior Response (90-100%): A superior response is a highly comprehensive, excellent reply that meets all of the requirements of the RFP. In addition, the response may cover areas not originally addressed within the RFP and/or include additional information and recommendations that would prove both valuable and beneficial to the agency.

Good Response (75-89%): A good response meets all the requirements of the RFP and demonstrates in a clear and concise manner a thorough knowledge and understanding of the project, with no deficiencies noted.

Fair Response (60-74%): A fair response minimally meets most requirements set forth in the RFP. The offeror demonstrates some ability to comply with guidelines and requirements of the project, but knowledge of the subject matter is limited.

Failed Response (59% or less): A failed response does not meet the requirements set forth in the RFP. The offeror has not demonstrated sufficient knowledge of the subject matter.

6.1 EVALUATION CRITERIA

Scope of Project 40% of points for a possible 600 pointsCategory Section of RFP Point Value

A. Project Management 3.1 150B. System Requirements 3.2 225C. Project Infrastructure 3.3 125D. Operational Support Requirements 3.4 100

References 1% of points for a possible 15 pointsCategory Section of RFP Point Value

A. References 4.1.1 15(Complete Contact Information Provided)

Company Profile and Experience 8% of points for a possible 120 pointsCategory Section of RFP Point Value

A. Years of Experience 4.1.2 20B. Past Projects 4.1.2 100

Method of Providing Services 4% of points for a possible 60 pointsCategory Section of RFP Point Value

A. Methods 4.1.3 30B. Work Plan 4.1.3 30

Financial Stability Pass/FailCategory Section of RFP Point Value

A. Financial Stability 4.1.4 Pass/Fail

Local Presence 3% of points for a possible 45 pointsCategory Section of RFP Point Value

A. Local Office 4.1.5 Pass/FailB. Local Staff 4.1.5 25C. Milestone Leads 4.1.5 20

Key Personnel 16% of points for a possible 240 pointsCategory Section of RFP Point Value

A. Project Manager Qualifications 4.1.6 40B. Database Administrator Qualifications 4.1.6 35C. Application Development Lead Qualifications 4.1.6 35D. Key Milestone Leads Qualifications 4.1.6 35E. System Engineer Qualifications 4.1.6 35F. Data Conversion Manager Qualifications 4.1.6 30G. Trainer Qualifications 4.1.6 30

Oral Presentation/Product Demonstration 8% of points for a possible 120 pointsCategory Section of RFP Point Value

A. Oral Presentation 4.1.7 50B. Product Demonstration 4.1.7 70

The State reserves the right to interview only the two highest scoring offerors, or to interview all offerors within 10% of the highest scoring offeror, or to interview all offerors who are deemed to have a passing score prior to the interview presentation process, at the State’s discretion.

Cost Proposal 20% of points for a possible 300 pointsCategory Section of RFP Point Value

A. Cost Proposal 5 300

Lowest overall cost receives the maximum allotted points. All other proposals receive a percentage of the points available based on their cost relationship to the lowest. Example: Total possible points for cost are 30. Offeror A’s cost is $20,000. Offeror B’s cost is $30,000. Offeror A would receive 30 points, Offeror B would receive 20 points ($20,000/$30,000) = 67% x 30 points = 20).

Lowest Responsive Offer Total Cost x Number of available points = Award PointsThis Offeror’s Total Cost

Bonus Points 100 possible points

100 bonus points are available for functionality not specifically requested which SOS determines would be a valuable addition to the project.

APPENDIX A: STANDARD TERMS AND CONDITIONS

By submitting a response to this invitation for bid, request for proposal, limited solicitation, or acceptance of a contract, the vendor agrees to acceptance of the following Standard Terms and Conditions and any other provisions that are specific to this solicitation or contract.

ACCEPTANCE/REJECTION OF BIDS, PROPOSALS, OR LIMITED SOLICITATION RESPONSES: The State reserves the right to accept or reject any or all bids, proposals, or limited solicitation responses, wholly or in part, and to make awards in any manner deemed in the best interest of the State. Bids, proposals, and limited solicitation responses will be firm for 30 days, unless stated otherwise in the text of the invitation for bid, request for proposal, or limited solicitation.

ALTERATION OF SOLICITATION DOCUMENT: In the event of inconsistencies or contradictions between language contained in the State’s solicitation document and a vendor’s response, the language contained in the State’s original solicitation document will prevail. Intentional manipulation and/or alteration of solicitation document language will result in the vendor’s disqualification and possible debarment.

AUTHORITY: The attached bid, request for proposal, limited solicitation, or contract is issued under authority of Title 18, Montana Code Annotated, and the Administrative Rules of Montana, Title 2, chapter 5.

CONFORMANCE WITH CONTRACT: No alteration of the terms, conditions, delivery, price, quality, quantities, or specifications of the contract shall be granted without prior written consent of the State Procurement Bureau. Supplies delivered which do not conform to the contract terms, conditions, and specifications may be rejected and returned at the contractor’s expense.

DEBARMENT: The contractor certifies, by submitting this bid or proposal, that neither it nor its principals are presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation in this transaction (contract) by any governmental department or agency. If the contractor cannot certify this statement, attach a written explanation for review by the State.

DISABILITY ACCOMMODATIONS: The State of Montana does not discriminate on the basis of disability in admission to, access to, or operations of its programs, services, or activities. Individuals who need aids, alternative document formats, or services for effective communications or other disability-related accommodations in the programs and services offered are invited to make their needs and preferences known to this office. Interested parties should provide as much advance notice as possible.

FACSIMILE RESPONSES: Facsimile responses will be accepted for invitations for bids, small purchases, or limited solicitations ONLY if they are completely received by the State Procurement Bureau prior to the time set for receipt. Bids, or portions thereof, received after the due time will not be considered. Facsimile responses to requests for proposals are ONLY accepted on an exception basis with prior approval of the procurement officer and ONLY if they are completely received by the State Procurement Bureau prior to the time set for receipt. Responses to RFPs, or portions thereof, received after the due time will not be considered.

FAILURE TO HONOR BID/PROPOSAL: If a bidder/offeror to whom a contract is awarded refuses to accept the award (PO/contract) or fails to deliver in accordance with the contract terms and conditions, the department may, in its discretion, suspend the bidder/offeror for a period of time from entering into any contracts with the State of Montana.

FORCE MAJEURE: Neither party shall be responsible for failure to fulfill its obligations due to causes beyond its reasonable control, including without limitation, acts or omissions of government or military authority, acts of God, materials shortages, transportation delays, fires, floods, labor disturbances, riots, wars, terrorist acts, or

any other causes, directly or indirectly beyond the reasonable control of the nonperforming party, so long as such party is using its best efforts to remedy such failure or delays.

LATE BIDS AND PROPOSALS: Regardless of cause, late bids and proposals will not be accepted and will automatically be disqualified from further consideration. It shall be solely the vendor’s risk to ensure delivery at the designated office by the designated time. Late bids and proposals will not be opened and may be returned to the vendor at the expense of the vendor or destroyed if requested.

PAYMENT TERM: All payment terms will be computed from the date of delivery of supplies or services OR receipt of a properly executed invoice, whichever is later. Unless otherwise noted in the solicitation document, the State is allowed 30 days to pay such invoices. All contractors will be required to provide banking information at the time of contract execution in order to facilitate State electronic funds transfer payments.

RECIPROCAL PREFERENCE: The State of Montana applies a reciprocal preference against a vendor submitting a bid from a state or country that grants a residency preference to its resident businesses. A reciprocal preference is only applied to an invitation for bid for supplies or an invitation for bid for nonconstruction services for public works as defined in section 18-2-401(9), MCA, and then only if federal funds are not involved. For a list of states that grant resident preference, see http://gsd.mt.gov/procurement/preferences.asp.

REFERENCE TO CONTRACT: The contract or purchase order number MUST appear on all invoices, packing lists, packages, and correspondence pertaining to the contract.

REGISTRATION WITH THE SECRETARY OF STATE: Any business intending to transact business in Montana must register with the Secretary of State. Businesses that are incorporated in another state or country, but which are conducting activity in Montana, must determine whether they are transacting business in Montana in accordance with sections 35-1-1026 and 35-8-1001, MCA. Such businesses may want to obtain the guidance of their attorney or accountant to determine whether their activity is considered transacting business.

If businesses determine that they are transacting business in Montana, they must register with the Secretary of State and obtain a certificate of authority to demonstrate that they are in good standing in Montana. To obtain registration materials, call the Office of the Secretary of State at (406) 444-3665, or visit their website at http://sos.mt.gov.

SEPARABILITY CLAUSE: A declaration by any court, or any other binding legal source, that any provision of the contract is illegal and void shall not affect the legality and enforceability of any other provision of the contract, unless the provisions are mutually dependent.

SHIPPING: Supplies shall be shipped prepaid, F.O.B. Destination, unless the contract specifies otherwise.

SOLICITATION DOCUMENT EXAMINATION: Vendors shall promptly notify the State of any ambiguity, inconsistency, or error which they may discover upon examination of a solicitation document.

TAX EXEMPTION: The State of Montana is exempt from Federal Excise Taxes (#81-0302402).

TECHNOLOGY ACCESS FOR BLIND OR VISUALLY IMPAIRED: Contractor acknowledges that no state funds may be expended for the purchase of information technology equipment and software for use by employees, program participants, or members of the public unless it provides blind or visually impaired individuals with access, including interactive use of the equipment and services, that is equivalent to that provided to individuals who are not blind or visually impaired. (Section 18-5-603, MCA.) Contact the State Procurement Bureau at (406) 444-2575 for more information concerning nonvisual access standards.

U.S. FUNDS: All prices and payments must be in U.S. dollars.

http://sos.mt.gov/

http://gsd.mt.gov/procurement/preferences.asp

WARRANTIES:

Warranty for Services:The contractor warrants that it performs all services using reasonable care and skill and according to its current description (including any completion criteria) contained in this contract. State agrees to provide timely written notice of any failure to comply with this warranty so that the contractor can take corrective action.

Warranty for Software: Upon initial installation of the software, the contractor warrants that: (i) the unmodified software will provide the features and functions, and will otherwise conform to all published documentation including on the contractor's website; and (ii) the media upon which the software is furnished will be free from defects in materials and workmanship under normal use and service.

Warranty for Hardware:The contractor warrants that hardware provided is free from defects in materials and workmanship and conforms to the specifications.

The warranty period for provided hardware is a fixed period commencing on the date specified in a statement of work or applicable contract. If the hardware does not function as warranted during the warranty period and the contractor is unable to either: i) make it do so; or ii) replace it with one that is at least functionally equivalent, State may return it to the contractor for a full refund.

The parties agree that the warranties set forth above do not require uninterrupted or error-free operation of hardware or services unless otherwise stated in the specifications.

THESE WARRANTIES ARE THE STATE’S EXCLUSIVE WARRANTIES AND REPLACE ALL OTHER WARRANTIES OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

2/08

APPENDIX B: INFORMATION TECHNOLOGY CONTRACT

1. Parties2. Effective Date, Duration, and Renewal3. Cost/Price Adjustments 4. Services and/or Supplies5. Consideration/Payment6. Access and Retention of Records7. Assignment, Transfer, and Subcontracting8. Limitation of Liability9. Required Insurance10. Compliance with Workers’ Compensation Act11. Compliance with Laws12. Intellectual Property/Ownership 13. Patent and Copyright Protection14. Contract Performance Assurance 15. Liquidated Damages16. Contract Oversight17. Contract Termination18. Event of Breach – Remedies19. Waiver of Breach20. State Personnel21. Contractor Personnel22. Meetings and Reports23. Contractor Performance Assessments24. Transition Assistance25. Choice of Law and Venue26. Scope, Amendment, and Interpretation27. Execution

SOS INFORMATION MANAGEMENT SYSTEM(INSERT CONTRACT NUMBER)

1. PARTIES

THIS CONTRACT is entered into by and between the State of Montana, Secretary of State’s Office, (hereinafter referred to as "the State"), whose address and phone number are PO Box 202801, Helena MT 59620-2801, (406) 444-2034, and (insert name of contractor), (hereinafter referred to as the "Contractor"), whose address and phone number are (insert address) and (insert phone number).

THE PARTIES AGREE AS FOLLOWS:

2. EFFECTIVE DATE, DURATION, AND RENEWAL

2.1 Contract Term. This contract shall take effect on upon contract execution and terminate on December 31, 2011, unless terminated earlier in accordance with the terms of this contract. (Section 18-4-313, MCA)

2.2 Contract Renewal. This contract may, upon mutual agreement between the parties and according to the terms of the existing contract, be renewed in one-year intervals, or any interval that is advantageous to the State. This contract, including any renewals, may not exceed a total of ten years, at the option of the State.

3. COST/PRICE ADJUSTMENTS

Cost Increase by Fixed Amount. After the initial term of this contract, each renewal term may be subject to a cost increase of (insert %) %, not to exceed (insert %) %, for the entire term of the contract.

4. SERVICES AND/OR SUPPLIES

The Contractor agrees to provide to the State Information Management System and related services as more fully detailed in the Contractor’s response to RFP08-1606P, as amended, and the Statement of Work attached hereto.

5. CONSIDERATION/PAYMENT

5.1 Payment Schedule. In consideration for the information management system and related services to be provided, the State shall pay according to the following schedule: (insert pay schedule from RFP response).

5.2 Withholding of Payment. The State may withhold disputed payments to the Contractor under the subject statement of work (or where no statement of work exists, the applicable contract) if the Contractor is in material breach of such statement of work (or applicable contract). Such withholding cannot be greater than, in the aggregate, fifteen percent (15%) of the total value of the subject statement of work or applicable contract. With respect to payments subject to milestone acceptance criteria, the State may withhold payment only for such specific milestone if and until the subject milestone criteria are met. The Contractor is not relieved of its performance obligation in the event such payment is withheld.

6. ACCESS AND RETENTION OF RECORDS

6.1 Access to Records. The Contractor agrees to provide the State, Legislative Auditor, or their authorized agents access to any records required to be made available by 18-1-118 MCA, in order to determine contract compliance.

6.2 Retention Period. The Contractor agrees to create and retain records supporting the information management system and related services for a period of three years after either the completion date of this contract or the conclusion of any claim, litigation, or exception relating to this contract taken by the State of Montana or a third party.

7. ASSIGNMENT, TRANSFER, AND SUBCONTRACTING

The Contractor shall not assign, transfer, or subcontract any portion of this contract without the express written consent of the State. (Section 18-4-141, MCA)

8. LIMITATION OF LIABILITY

The Contractor's liability for contract damages is limited to direct damages and further to no more than twice the contract amount. The Contractor shall not be liable for special, incidental, consequential, punitive, or indirect damages. Damages caused by injury to persons or tangible property, or related to intellectual property indemnification, are not subject to a cap on the amount of damages.

9. REQUIRED INSURANCE

9.1 General Requirements. The Contractor shall maintain for the duration of this contract, at its cost and expense, insurance against claims for injuries to persons or damages to property, including contractual liability, which may arise from or in connection with the performance of the work by the Contractor, agents, employees, representatives, assigns, or subcontractors. This insurance shall cover such claims as may be caused by any negligent act or omission.

9.2 Primary Insurance. The Contractor's insurance coverage with respect to the Contractor's negligence shall be primary insurance with respect to the State, its officers, officials, employees, and volunteers and shall apply separately to each project or location. Any insurance or self-insurance maintained by the State, its officers, officials, employees, or volunteers shall be excess of the Contractor's insurance and shall not contribute with it.

9.3 Specific Requirements for Commercial General Liability. The Contractor shall purchase and maintain occurrence coverage with combined single limits for bodily injury, personal injury, and property damage of $1,000,000 per occurrence and $2,000,000 aggregate per year to cover such claims as may be caused by any act, omission, or negligence of the Contractor or its officers, agents, representatives, assigns, or subcontractors.

The State, its officers, officials, employees, and volunteers are to be covered and listed as additional insureds; for liability arising out of activities performed by or on behalf of the Contractor, including the insured's general supervision of the Contractor; products and completed operations; premises owned, leased, occupied, or used.

9.4 Deductibles and Self-Insured Retentions. Any deductible or self-insured retention must be declared to and approved by the state agency. At the request of the agency, the Contractor will elect to either: (1) the insurer shall reduce or eliminate such deductibles or self-insured retentions as respects the State, its officers, officials, employees, or volunteers; or (2) at the expense of the Contractor, the Contractor shall procure a bond guaranteeing payment of losses and related investigations, claims administration, and defense expenses.

9.5 Certificate of Insurance/Endorsements. A certificate of insurance from an insurer with a Best's rating of no less than B++ indicating compliance with the required coverages, has been received by the State Procurement Bureau, PO Box 200135, Helena MT 59620-0135. The Contractor must notify the State immediately, of any material change in insurance coverage, such as changes in limits, coverages, change in status of policy, etc. The State reserves the right to require certificates of insurance policies at all times.

10. COMPLIANCE WITH WORKERS' COMPENSATION ACT

Contractors are required to comply with the provisions of the Montana Workers' Compensation Act while performing work for the State of Montana in accordance sections 39-71-401, 39-71-405, and 39-71-417, MCA. Proof of compliance must be in the form of workers' compensation insurance, an independent contractor's exemption, or documentation of corporate officer status. Neither the Contractor nor its employees are employees of the State. This insurance/exemption must be valid for the entire term of this contract. A renewal document must be sent to the State Procurement Bureau, PO Box 200135, Helena MT 59620-0135, upon expiration.

11. COMPLIANCE WITH LAWS

The Contractor must, in performance of work under this contract, fully comply with all applicable federal, state, or local laws, rules, and regulations, including the Montana Human Rights Act, the Civil Rights Act of 1964, the Age Discrimination Act of 1975, the Americans with Disabilities Act of 1990, and Section 504 of the Rehabilitation Act of 1973. Any subletting or subcontracting by the Contractor subjects subcontractors to the same provision. In accordance with section 49-3-207, MCA, the Contractor agrees that the hiring of persons to perform this contract will be made on the basis of merit and qualifications and there will be no discrimination based upon race, color, religion, creed, political ideas, sex, age, marital status, physical or mental disability, or national origin by the persons performing this contract.

12. INTELLECTUAL PROPERTY/OWNERSHIP

12.1 Mutual Use. All patent and other legal rights in or to inventions first conceived and reduced to practice, created in whole or in part under this contract, must be available to the State for royalty-free and nonexclusive licensing if necessary to receive the mutually agreed upon benefit under this contract. Unless otherwise specified in a statement of work, both parties shall have a royalty-free, nonexclusive, and irrevocable right to reproduce, publish, or otherwise use and authorize others to use copyrightable property created under this contract including all deliverables and other materials, products, modifications developed or prepared for the State by the Contractor under this contract or any program code, including site related program code, created, developed, or prepared by the Contractor under or primarily in support of the performance of its specific obligations hereunder, including manuals, training materials, and documentation (the "Work Product").

12.2 Title and Ownership Rights. The State shall retain title to and all ownership rights in all data and content, including but not limited to multimedia or images (graphics, audio, and video), text, and the like provided by the State (the "content"), but grants the Contractor the right to access and use content for the purpose of complying with its obligations under this contract and any applicable statement of work.

12.3 Ownership of Work Product. The Contractor agrees to execute any documents or take any other actions as may reasonably be necessary, or as the State may reasonably request, to perfect the State's ownership of any Work Product.

12.4 Copy of Work Product. The Contractor shall, at no cost to the State, deliver to the State, upon the State's request during the term or at the expiration or termination of all or part of the Contractor's performance hereunder, a current copy of all Work Product in the form and on the media in use as of the date of the State's request, or as of such expiration or termination, as the case may be.

12.5 Ownership of Contractor Pre-Existing Materials. Literary works or other works of authorship (such as software programs and code, documentation, reports, and similar works), information, data, intellectual property, techniques, subroutines, algorithms, methods or rights thereto and derivatives thereof owned by the Contractor at the time this contract is executed or otherwise developed or acquired independent of this contract and employed by the Contractor in connection with the services provided to the State (the "Contractor Pre-Existing Materials") shall be and remain the property of the Contractor and do not constitute Work Product. The Contractor must provide full disclosure of any Contractor Pre-Existing Materials to the State prior to its use and prove its ownership, provided, however, that if the Contractor fails to disclose to the State

such Contractor Pre-Existing Materials, the Contractor shall grant the State a nonexclusive, worldwide, paid-up license to use any Contractor Pre-Existing Materials embedded in the Work Product to the extent such Contractor Pre-Existing Materials are necessary for the State to receive the intended benefit under this contract. Such license shall remain in effect for so long as such Pre-Existing Materials remain embedded in the Work Product. Except as otherwise provided for in Section 12.3 or as may be expressly agreed in any statement of work, the Contractor shall retain title to and ownership of any hardware provided by the Contractor.

13. PATENT AND COPYRIGHT PROTECTION

13.1 Third-Party Claim. In the event of any claim by any third party against the State that the products furnished under this contract infringe upon or violate any patent or copyright, the State shall promptly notify the Contractor. The Contractor shall defend such claim, in the State's name or its own name, as appropriate, but at the Contractor's expense. The Contractor will indemnify the State against all costs, damages, and attorney's fees that accrue as a result of such claim. Such indemnification will be conditional upon the following:

a. the State will promptly notify the Contractor of the claim in writing; andb. the State will allow the Contractor to control, and will cooperate with the Contractor in the defense

and any related settlement negotiations, provided that:i. the Contractor will permit the State to participate in the defense and settlement of any such

claim, at the State's own expense, with counsel of its choosing; andii. the Contractor shall not enter into or agree to any settlement containing any admission of or

stipulation to any guilt, fault, liability or wrongdoing on the part of the State, its elected and appointed officials, agents or employees without the State's prior written consent.

13.2 Product Subject of Claim. If any product furnished is likely to or does become the subject of a claim of infringement of a patent or copyright, then the Contractor may, at its option, procure for the State the right to continue using the alleged infringing product, or modify the product so that it becomes noninfringing or replace it with one that is at least functionally equivalent. If none of the above options can be accomplished, or if the use of such product by the State shall be prevented by injunction, the State agrees to return the product to the Contractor on written request. The Contractor will then give the State a credit equal to the amount paid to the Contractor for the creation of the Work Product. This is the Contractor's entire obligation to the State regarding a claim of infringement. The State is not precluded from seeking other remedies available to it hereunder, including Section 8, and in equity or law for any damages it may sustain due to its inability to continue using such product.

13.3 Claims for Which Contractor Is Not Responsible. The Contractor has no obligation regarding any claim based on any of the following except where the Contractor has agreed in writing, either separately or within this contract, to such use that is the basis of the claim:

a. anything the State provided which is incorporated into a Work Product except:i. where the Contractor knew (and the State did not know) such thing was infringing at the time of

its incorporation into a Work Product but failed to advise the State; orii. where the claim would not have been brought except for such incorporation;

b. the State's modification of a Work Product furnished under this contract;c. the use of a Work Product in a manner that could not be reasonably contemplated within the agreed

upon scope of the applicable project; ord. infringement by a non-Contractor Work Product alone.

14. CONTRACT PERFORMANCE ASSURANCE

14.1 Milestone Payments. Payments to the Contractor will be based on completion and acceptance of each milestone defined below.

14.2 Payment Holdbacks. ___ % will be withheld from each milestone payment. The total amount withheld will be paid to the Contractor at the completion and acceptance of the final milestone.

Milestone/Deliverable Hold Back Payment % of Total

Milestone 1: ___% of approved invoice %





Final Acceptance 100%

14.3 Escrow. [May be used if the solution contains COTS or COTS/Development blended software.] All relevant source code shall be deposited with an independent escrow agent by the Contractor during the development and implementation phases of this contract. The source code must be updated with the escrow agent at least monthly. The State shall be listed as the beneficiary. The Contractor must send certification to the State that this escrow is in place. The conditions under which the materials will be released to the State include, the Contractor ceases doing business, the Contractor files for bankruptcy, a breach of this contract, this contract comes to an end and all source code has not been delivered by the Contractor.

14.4 Contract Performance Security – Surety Bonds Only. The Contractor must provide contract performance security based upon 100% of the contract total. This security must be in the form of a surety bond licensed in Montana with a Best's rating of no less than B++. The surety bond must be supplied on the form designated by the State of Montana. The required form entitled "Contract Performance Bond," may be found at http://gsd.mt.gov/procurement/forms.asp. THE ORIGINAL FORM MUST BE PROVIDED. FACSIMILE, ELECTRONIC, OR PHOTOCOPIES ARE NOT ACCEPTABLE.

The contract performance security must be provided to the State of Montana within 10 working days from the Request for Documents Notice. This security must remain in effect for the entire term of this contract. A new surety bond must be issued to the State of Montana if this contract is renewed.

The original surety bond form has been provided to the following address: State Procurement Bureau, PO Box 200135, Helena MT 59620-0135.

15. LIQUIDATED DAMAGES

The State of Montana reserves the right to assess liquidated damages as follows:

a. Conversion Overview. SOS systems support mission critical applications that cannot tolerate outages due to conversion issues. Any disruption during the conversion or disruption as a result of the conversion during the term of the contract is not acceptable and will be subject to liquidated damages in the amount of $ per calendar day. (Reference RFP Section 3.3.6)

b. Backup. In the event of a disaster, failure of the Contractor’s components of the disaster recovery procedure to fully restore SIMS to operating condition shall subject the Contractor to liquidated damages in the amount of $ per calendar day, regardless of what kind of disaster causes such conditions to occur. (Reference RFP Section 3.3.12.2)

http://gsd.mt.gov/procurement/forms.asp

c. Issues, Enhancements, and Defects. Failure by the Contractor to provide resolution for Operational Support-related events, such as questions, service requests, or system generated exceptions within the agreed upon resolution time period may subject the Contractor to liability for liquidated damages in the amount of $ per calendar day. (Reference RFP Section 3.4.1)

d. Help Desk. The Contractor may request the SOS Project Manager to grant an extension beyond the agreed upon resolution time period, and the SOS Project Manager may grant such an extension, provided the Contractor has demonstrated due diligence in pursuing diagnosis and correction for the event question, service request, or system generated exception. Resolution within the required time period, or possible extension thereof, does not reduce the Contractor's liability for liquidated damages. (Reference RFP Section 3.4.1.1)

These sums may be deducted from the Contractor’s payment for failure to deliver/perform when specified. No premium will be awarded to the Contractor for delivery/performance in advance of the specified time. The amount of actual damages may be offset by liquidated damages taken.

16. CONTRACT OVERSIGHT

16.1 CIO Oversight. The Chief Information Officer (CIO) for the State of Montana, or designee, may perform contract oversight activities. Such activities may include the identification, analysis, resolution, and prevention of deficiencies that may occur within the performance of contract obligations. The CIO may require the issuance of a right to assurance or the issuance of a stop work order.

16.2 Right to Assurance. If the State, in good faith, has reason to believe that the Contractor does not intend to, or is unable to perform or has refused to perform or continue performing all material obligations under this contract, the State may demand in writing that the Contractor give a written assurance of intent to perform. Failure by the Contractor to provide written assurance within the number of days specified in the demand (in no event less than five (5) business days) may, at the State's option, be the basis for terminating this contract under the terms and conditions or other rights and remedies available by law or provided by this contract.

16.3 Stop Work Order. The State may, at any time, by written order to the Contractor, require the Contractor to stop any or all parts of the work required by this contract for the period of days indicated by the State after the order is delivered to the Contractor. The order shall be specifically identified as a stop work order issued under this clause. Upon receipt of the order, the Contractor shall immediately comply with its terms and take all reasonable steps to minimize the incurrence of costs allocable to the work covered by the order during the period of work stoppage. If a stop work order issued under this clause is canceled or the period of the order or any extension expires, the Contractor shall resume work. The State Project Manager shall make the necessary adjustment in the delivery schedule or contract price, or both, and this contract shall be amended in writing accordingly.

17. CONTRACT TERMINATION

17.1 Termination for Cause. The State or the Contractor may, by written notice to the other party, terminate this contract in whole or in part at any time the other party fails to perform this contract pursuant to Section 18, Event of Breach – Remedies.

17.2 Bankruptcy or Receivership. Voluntary or involuntary bankruptcy or receivership by the Contractor may be cause for termination.

17.3 Noncompliance with Department of Administration Requirements. The Department of Administration, pursuant to section 2-17-514, MCA, retains the right to cancel or modify any contract, project, or activity that is not in compliance with the Department's Plan for Information Technology, the State Strategic Plan for Information Technology, or any Statewide IT policy or standard in effect as of the date of contract

execution. In the event of such termination, the State will pay for products and services delivered to date and any applicable termination fee specified in the statement of work or work order. Any modifications to this contract must be mutually agreed to by the parties.

17.4 Reduction of Funding. The State, at its sole discretion, may terminate or reduce the scope of this contract if available funding is reduced for any reason. (See section 18-4-313(4), MCA.)

18. EVENT OF BREACH – REMEDIES

18.1 Event of Breach. Any one or more of the following acts or omissions of the Contractor shall constitute an event of breach:

a. products or services furnished by the Contractor fail to conform to any requirement of this contract; or

b. failure to submit any report required by this contract; orc. failure to perform any of the other covenants and conditions of this contract, including beginning

work under this contract without prior Department of Administration approval.

18.2 Actions in Event of Breach. Upon the occurrence of any material breach of this contract, either party may take either one, or both, of the following actions:

a. give the breaching party a written notice specifying the event of breach and requiring it to be remedied within, in the absence of a greater specification of time, thirty (30) days from the date of the notice; and if the event of breach is not timely remedied, terminate this contract upon giving the breaching party notice of termination; or

b. treat this contract as materially breached and pursue any of its remedies at law or in equity, or both.

19. WAIVER OF BREACH

No failure by either party to enforce any provisions hereof after any event of breach shall be deemed a waiver of its rights with regard to that event, or any subsequent event. No express failure of any event of breach shall be deemed a waiver of any provision hereof. No such failure or waiver shall be deemed a waiver of the right of either party to enforce each and all of the provisions hereof upon any further or other breach on the part of the breaching party.

20. STATE PERSONNEL

20.1 State Contract Manager. The State Contract Manager identified below is the State's single point of contact and will perform all contract management pursuant to section 2-17-512, MCA, on behalf of the State. Written notices, requests, complaints, or any other issues regarding this contract should be directed to the State Contract Manager.

The State Contract Manager for this contract is:(Name):(Address):(City, State, ZIP):Telephone #:Cell Phone #:Fax #:E-mail:

20.2 State Project Manager. The State Project Manager identified below will manage the day-to-day project activities on behalf of the State.

The State Project Manager for this contract is:

(Name):(Address):(City, State, ZIP):Telephone #:Cell Phone #:Fax #:E-mail:

21. CONTRACTOR PERSONNEL

21.1 Identification/Substitution of Personnel. The personnel identified or described in the Contractor's proposal shall perform the services provided for the State under this contract. The Contractor agrees that any personnel substituted during the term of this contract must be able to conduct the required work to industry standards and be equally or better qualified than the personnel originally assigned. The State reserves the right to approve the Contractor personnel assigned to work under this contract, and any changes or substitutions to such personnel. The State's approval of a substitution will not be unreasonably withheld. This approval or disapproval shall not relieve the Contractor to perform and be responsible for its obligations under this contract. The State reserves the right to require Contractor personnel replacement. In the event that Contractor personnel become unavailable, it will be the Contractor's responsibility to provide an equally qualified replacement in time to avoid delays to the work plan.

21.2 Contractor Contract Manager. The Contractor Contract Manager identified below will be the single point of contact to the State Contract Manager and will assume responsibility for the coordination of all contract issues under this contract. The Contractor Contract Manager will meet with the State Contract Manager and/or others necessary to resolve any conflicts, disagreements, or other contract issues.

The Contractor Contract Manager for this contract is:(Name):(Address):(City, State, ZIP):Telephone #:Cell Phone #:Fax #:E-mail:

21.3 Contractor Project Manager. The Contractor Project Manager identified below will manage the day-to-day project activities on behalf of the Contractor:

The Contractor Project Manager for this contract is:(Name):(Address):(City, State, ZIP):Telephone #:Cell Phone #:Fax #:E-mail:

22. MEETINGS AND REPORTS

22.1 Technical or Contractual Problems. The Contractor is required to meet with the State's personnel, or designated representatives, at no additional cost to the State, to resolve technical or contractual problems that may occur during the term of this contract. Meetings will occur as problems arise and will be coordinated by the State. Failure to participate in problem resolution meetings or failure to make a good faith effort to resolve problems may result in termination of this contract.

22.2 Progress Meetings. During the term of this contract, the State's Project Manager will plan and schedule progress meetings with the Contractor to discuss the progress made by the Contractor and the State in the performance of their respective obligations. These progress meetings will include the State Project Manager, the Contractor Project Manager, and any other additional personnel involved in the performance of this contract as required. At each such meeting, the Contractor shall provide the State with a written status report that identifies any problem or circumstance encountered by the Contractor, or of which the Contractor gained knowledge during the period since the last such status report, which may prevent the Contractor from completing any of its obligations or may generate charges in excess of those previously agreed to by the parties. This may include the failure or inadequacy of the State to perform its obligation under this contract. The Contractor shall identify the amount of excess charges, if any, and the cause of any identified problem or circumstance and the steps taken to remedy the same.

22.3 Failure to Notify. In the event the Contractor fails to specify in writing any problem or circumstance that materially impacts the costs of its delivery hereunder, including a material breach by the State, about which the Contractor knew or reasonably should have known with respect to the period during the term covered by the Contractor's status report, the Contractor shall not be entitled to rely upon such problem or circumstance as a purported justification for an increase in the price for the agreed upon scope; provided, however, that the Contractor shall be relieved of its performance obligations to the extent the acts or omissions of the State prevent such performance.

22.4 State's Failure or Delay. For a problem or circumstance identified in the Contractor's status report in which the Contractor claims was the result of the State's failure or delay in discharging any State obligation, the State shall review same and determine if such problem or circumstance was in fact the result of such failure or delay. If the State agrees as to the cause of such problem or circumstance, then the parties shall extend any deadlines or due dates affected thereby, and provide for any additional charges by the Contractor. If the State does not agree as to the cause of such problem or circumstance, the parties shall each attempt to resolve the problem or circumstance in a manner satisfactory to both parties.

23. CONTRACTOR PERFORMANCE ASSESSMENTS

23.1 Assessments. The State may conduct assessments of the Contractor's performance. The Contractor will have an opportunity to respond to assessments, and independent verification of the assessment may be utilized in the case of disagreement.

23.2 Record. Completed assessments may be kept on record at the State's Information Technology Services Division and may serve as past performance data. Past performance data will be available to assist agencies in the selection of IT service providers for future projects. Past performance data may also be utilized in future procurement efforts.

24. TRANSITION ASSISTANCE

If this contract is not renewed at the end of this term, or is terminated prior to the completion of a project, or if the work on a project is terminated for any reason, the Contractor must provide for a reasonable, mutually agreed period of time after the expiration or termination of this contract, all reasonable transition assistance requested by the State, to allow for the expired or terminated portion of the services to continue without interruption or adverse effect, and to facilitate the orderly transfer of such services to the State or its designees. Such transition assistance will be deemed by the parties to be governed by the terms and conditions of this contract, except for those terms or conditions that do not reasonably apply to such transition assistance. The State shall pay the Contractor for any resources utilized in performing such transition assistance at the most current rates provided by this contract. If there are no established contract rates, then the rate shall be mutually agreed upon. If the State terminates a project or this contract for cause, then the State will be entitled to offset the cost of paying the Contractor for the additional resources the Contractor utilized in providing transition assistance with any damages the State may have otherwise accrued as a result of said termination.

25. CHOICE OF LAW AND VENUE

This contract is governed by the laws of Montana. The parties agree that any litigation concerning this bid, proposal or subsequent contract must be brought in the First Judicial District in and for the County of Lewis and Clark, State of Montana and each party shall pay its own costs and attorney fees. (See section 18-1-401, MCA.)

26. SCOPE, AMENDMENT, AND INTERPRETATION

26.1 Contract. This contract consists of (insert number) numbered pages, any Attachments as required, RFP # 08-1606P, as amended, and the Contractor's RFP response as amended. In the case of dispute or ambiguity about the minimum levels of performance by the Contractor the order of precedence of document interpretation is as follows: 1) amendments to this contract, 2) this contract, 3) the applicable statement of work, 4) RFP # 08-1606P, as amended, and 5) the Contractor's RFP response, as amended.

26.2 Entire Agreement. These documents contain the entire agreement of the parties. Any enlargement, alteration or modification requires a written amendment signed by both parties.

27. EXECUTION

The parties through their authorized agents have executed this contract on the dates set out below.

SECRETARY OF STATE’S OFFICE (INSERT CONTRACTOR'S NAME)PO BOX 202801 (Insert Address)HELENA MT 59620-2801 ( Insert City, State, Zip)

FEDERAL ID #

BY: BY: (Name/Title) (Name/Title)

(Signature) (Signature)

DATE: DATE:

Approved as to Legal Content:

Legal Counsel (Date)

Approved as to Form:

Procurement Officer (Date)State Procurement Bureau

Chief Information Officer Approval:

The Contractor is notified that pursuant to section 2-17-514, MCA, the Department of Administration retains the right to cancel or modify any contract, project, or activity that is not in compliance with the Agency's Plan for

Information Technology, the State Strategic Plan for Information Technology, or any statewide IT policy or standard.

Chief Information Officer (Date)Department of Administration