Docstoc

Final Draft

Document Sample
Final Draft Powered By Docstoc
					                                    STATE OF MONTANA
                               REQUEST FOR PROPOSAL (RFP)
                              FOR INFORMATION TECHNOLOGY
RFP Number:            RFP Title:
RFP08-1606P            SOS INFORMATION MANAGEMENT SYSTEM
     RFP Response Due Date and Time:
             FRIDAY, JULY 18, 2008           Number of Pages: 69
             2:00 p.m., Local Time

                               ISSUING AGENCY INFORMATION
Procurement Officer:                                                   Issue Date:
Penny Moon                                                             June 4, 2008
          State Procurement Bureau
                                                         Phone: (406) 444-2575
          General Services Division
                                                          Fax: (406) 444-2529
        Department of Administration
                                                          TTY Users, Dial 711
         Room 165, Mitchell Building
           125 North Roberts Street
               P.O. Box 200135
                                                     Website: http://vendor.mt.gov/
            Helena, MT 59620-0135

                                INSTRUCTIONS TO OFFERORS
Return Sealed Proposal to:                   Mark Face of Envelope/Package:

         State Procurement Bureau        RFP Number: RFP08-1606P
          General Services Division      RFP Response Due Date: 07/18/08
        Department of Administration
         Room 165, Mitchell Building     Special Instructions:
          125 North Roberts Street
              P.O. Box 200135
           Helena, MT 59620-0135
                  IMPORTANT: SEE STANDARD TERMS AND CONDITIONS

                     OFFERORS MUST COMPLETE THE FOLLOWING
Offeror 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
                                                     TABLE OF CONTENTS
                                                                                                                                                      PAGE

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

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

Section 1: Project Overview and Instructions ......................................................... 5
        1.0     Project Overview ........................................................................................................................ 5
        1.1     Contract Term ............................................................................................................................ 5
        1.2     Single Point of Contact ............................................................................................................... 5
        1.3     Required Review ........................................................................................................................ 5
        1.4     Pre-Proposal Conference ........................................................................................................... 6
        1.5     General Requirements ............................................................................................................... 6
        1.6     Submitting a Proposal ................................................................................................................ 7
        1.7     Cost of Preparing a Proposal ...................................................................................................... 8
Section 2:       RFP Standard Information ....................................................................... 9
        2.0     Authority ..................................................................................................................................... 9
        2.1     Offeror Competition .................................................................................................................... 9
        2.2     Receipt of Proposals and Public Inspection ................................................................................ 9
        2.3     Classification and Evaluation of Proposals ................................................................................. 9
        2.4     State‟s Rights Reserved ........................................................................................................... 11
        2.5     Department of Administration Powers and Duties ..................................................................... 11
        2.6     Compliance with State of Montana IT Standards ...................................................................... 11
Section 3:       Scope of Project ...................................................................................... 13
        3.0     Introduction .............................................................................................................................. 13
        3.1     Project Management ................................................................................................................ 15
        3.2     System Requirements .............................................................................................................. 27
        3.3     Project Infrastructure ................................................................................................................ 37
        3.4     Operational Support Requirements .......................................................................................... 45
Section 4:       Offeror Qualifications/Informational Requirements ............................. 48
        4.0     State‟s Right to Investigate and Reject ..................................................................................... 48
        4.1     Offeror Qualifications/Informational Requirements.................................................................... 48
Section 5:       Cost Proposal.......................................................................................... 50
        5.0     Cost Proposal ........................................................................................................................... 50
        5.1     Required Pricing Information .................................................................................................... 50
        5.2     Payment Schedule ................................................................................................................... 51
Section 6:       Evaluation Process ................................................................................. 52
        6.0     Basis of Evaluation ................................................................................................................... 52
        6.1     Evaluation Criteria .................................................................................................................... 52

Appendix A - Standard Terms and Conditions ........................................................ 55
Appendix 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).




                                                     RFP08-1606P, SOS Information Management System, Page 3
                                         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




                                                        RFP08-1606P, SOS Information Management System, Page 4
                 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 Moon
                                          State Procurement Bureau
                                          Room 165, Mitchell Building
                                              125 North Roberts
                                               PO Box 200135
                                           Helena MT 59620-0135
                                            Phone: (406) 444-3313
                                             Fax: (406) 444-2529
                                           E-mail: pmoon@mt.gov

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.



                                                       RFP08-1606P, SOS Information Management System, Page 5
       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 pmoon@mt.gov 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

                                                        RFP08-1606P, SOS Information Management System, Page 6
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



                                                        RFP08-1606P, SOS Information Management System, Page 7
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.




                                                        RFP08-1606P, SOS Information Management System, Page 8
                          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


                                                         RFP08-1606P, SOS Information Management System, Page 9
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

                                                      RFP08-1606P, SOS Information Management System, Page 10
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

                                                       RFP08-1606P, SOS Information Management System, Page 11
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 Plan
http://itsd.mt.gov/stratplan/statewideplan.asp

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

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

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




                                                     RFP08-1606P, SOS Information Management System, Page 12
                                 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 requirements
        3.3 Project Infrastructure – items and tasks related to system environment and infrastructure
        3.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

                                                      RFP08-1606P, SOS Information Management System, Page 13
      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.).

                                                      RFP08-1606P, SOS Information Management System, Page 14
         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

                                                        RFP08-1606P, SOS Information Management System, Page 15
      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

                                                     RFP08-1606P, SOS Information Management System, Page 16
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.


                                                      RFP08-1606P, SOS Information Management System, Page 17
        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

                                                     RFP08-1606P, SOS Information Management System, Page 18
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.




                                                      RFP08-1606P, SOS Information Management System, Page 19
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:

                                                      RFP08-1606P, SOS Information Management System, Page 20
          o   Description of the enhancement, including impact if not done
          o   Scope
          o   Benefits and drawbacks
          o   Effects on current design
          o   Impacts on completed system components
          o   Costs
          o   Impacts to hardware and software (including capacity)
          o   Effects on SOS staffing and skill requirements
          o   Project schedule
          o   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.




                                                     RFP08-1606P, SOS Information Management System, Page 21
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.



                                                       RFP08-1606P, SOS Information Management System, Page 22
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.

                                                                                   3rd Party
Roles and Responsibilities                                                           IV&V         Offeror         State
I. Program Management
A. Operate Program Management Office (PMO)                                                       S            L
B. Manage Offeror component of Project Team                                                      L            S
C. Manage State component of Project Team                                                        S            L
II. Independent Validation and Verification (IV&V)
A. Perform project IV&V if the State exercises its option for requiring this L                   S            S
    type of oversight.
III. Technology Management
A. Recommend technology platform that best meets SOS business needs                              L            S
    and expense/service level expectations
B. Authorize and approve technology platform                                                     S            L
C. Recommend policies and procedures                                                             S            L
D. Authorize and approve policies and procedures                                                 S            L
E. Define services and standards                                                                 S            L
F. Manage/track development requests and orders                                                  S            L
IV. Planning/Requirements/Design
A. Design data structures                                                                        L            S
B. Design program modules                                                                        L            S
C. Determine & manage functional requirements                                                    S            L
D. Recommend service level requirements                                                          L            S
E. Authorize and approve requirements definition                                                 S            L
F. Develop cost/benefit analysis                                                                 S            L
G. Obtain management authorization                                                               S            L
V. Programming
A. Develop functional specifications                                                             L            S
B. Create program code                                                                           L            S
C. Conduct unit testing of modules                                                               L            S
D. Transfer programs to Offeror Quality Assurance                                                L            S
E. Develop version control methodology                                                           L            S
VI. Software Integration & Testing
A. Test system conformance to functional requirements                                            L            S
B. Test system conformance to usability standards                                                L            S
C. Conduct user acceptance testing                                                               S            L
D. Ensure system conformance to naming/operational conventions                                   S            L
E. Review and approve quality assurance testing                                                  S            L
F. Repair defects                                                                                L            S
Continued on next page….




                                                        RFP08-1606P, SOS Information Management System, Page 23
 Roles and Responsibilities                                          3rd Party IV&V       Offeror        State
 VII. Implementation
 A. Install local system components as needed                                            S           L
 B. Train local system users                                                             L           S
 C. Provide in-person assistance during initial implementation                           L           S
 period
 D. Review and approve application implementation                                        S           L
 E. Develop disaster recovery plan and procedures                                        S           L
 VIII. Data Base Administration
 A. Perform data modeling                                                                L           S
 B. Create logical database design                                                       L           S
 C. Create physical database design                                                      L           S
 D. Determine data element naming conventions                                            L           S
 E. Determine data element access levels                                                 L           S
 F. Monitor compliance with naming conventions                                           S           L
 G. Determine logical views of database                                                  L           S
 H. Recommend DBMS/tools for implementation                                              L           S
 I. Perform technical review of DBMS code                                                L           S
 J. Monitor DBMS performance                                                             L           S
 K. Recommend DBMS performance optimization measures                                     L           S
 L. Design database backup and recovery procedures                                       L           S
 M. Develop database backup and recovery procedures                                      S           L
 N. Assist in test-to-production application turnover                                    L           S
 O. Provide technical support of DBMS as needed                                          L           S
 IX. Data Conversion & Quality
 A. Recommend data conversion strategies                                                 L           S
 B. Perform data conversion extract and minor cleaning                                   S           L
 C. Perform data conversion transform, import and loading                                L           S
 D. Perform data cleansing                                                               S           L
 E. Perform data validation                                                              S           L
 X. Accounting & Reporting
 A. Assign user account codes                                                            S           L
 B. Maintain tables of client account codes                                              S           L
 C. Maintain and allocate budget                                                         S           L
 D. Track utilization                                                                    S           L
 E. Monitor cost center invoices                                                         S           L
 F. Send invoices                                                                        L           S
 G. Respond to the State‟s stakeholder inquiries                                         S           L
 H. Report on project execution metrics                                                  S           L
 I. Provide status reports and metrics                                                   L           S
 J. Provide state agency status reports                                                  S           L
Continued on next page….




                                                     RFP08-1606P, SOS Information Management System, Page 24
                                                                            3rd Party
Roles and Responsibilities                                                  IV&V          Offeror        State
XI. Change Management Control
A. Establish change management controls                                                   L              S
B. Establish change requirements                                                          L              S
C. Determine and manage risk                                                              L              S
D. Determine change cost and impact                                                       L              S
E. Schedule and conduct change management meetings                                        L              S
F. Authorize and approve change                                                           S              L
G. Notify affected clients of change timing and impact                                    L              S
H. Implement change                                                                       L              S
I. Verify change met objectives and no negative impacts                                   L              S
J. Validate & Report results of change                                                    S              L
K. Perform quality control                                                                S              L
XII. Security
A. Establish security requirements & rights                                               S              L
B. Maintain physical security of assets                                                   S              L
C. Conduct periodic security checks per requirements                                      S              L
D. Report security violations & weaknesses identified                                     L              S
E. Resolve security violations                                                            L              S
XIII. Training and Knowledge Transfer
A. Plan and Execute Training                                                              L              S
B. Provide Training Materials                                                             L              S
C. Knowledge Transfer                                                                     L              S
XIV. Documentation
A. Provide user documentation                                                             L              S
B. Provide technical documentation                                                        L              S
C. Provide operations documentation                                                       L              S
D. 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.

                                                     RFP08-1606P, SOS Information Management System, Page 25
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.




                                                      RFP08-1606P, SOS Information Management System, Page 26
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

                                                     RFP08-1606P, SOS Information Management System, Page 27
        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:




                                                       RFP08-1606P, SOS Information Management System, Page 28
          SOS INFORMATION
      MANAGEMENT SYSTEM (SIMS)                                                                                                      If cash
                                                                              A. MAILROOM & WALK-IN PROCESSING
     PROCESSING UNIT WORK FLOW                                                                                                                  C1
       High level (all interfaces, batch processes, and                                      Sub-batches
               tracking areas are not shown)
                                                                                                                              If only $ or dishonored
                                                                                                                                  payment check
                                                                                       B. RECEIPTING STEP
 B2. AU IUJ PENDING                                                                                                                             G.
                              B1. SOS WEBSITE PENDING
RECEIPTING TRACKING                                                                              Batch
                               RECEIPTING REPOSITORY
        AREA                                                                                   Sub-batch
                              (ARNU & FILLABLE FORMS)
                                                                                                 Event
          IUJ Data                                                                            Transaction                                       D.
                                      Request Data
Links to Requests & Invoice
                                    (Filings & Orders)
         Statements                                                           Event Status: accept/reject/pending + reason
                                                                            Batch/Sub-batch Status: open/closed/suspended                     If checks
                                     Status: pending
     Status: pending                                                       Imagable Document Label: TN + form # + # pages
                                                                              Batch Label: Retention Content ID + Batch #


                                    C1. TREASURY
                                      DEPOSITS
                                                                                     C. RECONCILIATION STEP
                A.                   personal check
                                                                                  SIMS check $ = adding tape $
                                      money orders
                                                                              amount due activity = amount paid activity
                                     cashiers check
                                          cash


                                                                                         D. IMAGING STEP
                               D1. INTERNET SERVICES
                                  PENDING IMAGING                                                Batch
                                     REPOSITORY                                                Sub-batch
                                                                                                 Event
              B., F.,
                                      Request Data                                            Transaction
               G.
                                   (Incomplete Orders)
                                                                                     Redaction (Auto and Manual)
                                    Status: pending
                                Processing source: IS/PU                       Index #: TN + Filing/Order # if accepted
                                                                                        Layer: original/altered


                                    E1. FILE PAPER

                                UCC & Non-UCC Folders                                E. RECONCILIATION STEP

                                          Batch                               # of receipted documents = # imaged docs
                                        Sub-batch                               # of receipted pages = # imaged pages
                                          Event
                                       Transaction

                                                                                       F. COMPLIANCE STEP
                                 F1. TRACKING AREA
                                       UPDATE
                                                                                 Work Queues (Request Category &
                                                                                           Request Type)
                                   Customer Requests
                                                                                    Compliance Transaction (CT)
                                        Filing #
                                                                               Available Payment Amount +/- Tracking
                                        Order #                                                                                                D.
                                                                                Linked to Sub-batch Data and Images
                                                                   If
                                 Status: active/inactive +      accepted    Event Status: accept/reject/pending + reason           If request form change
                                          reason
                                                                            CT Status: open/close/pending/transfer in/out/
                                 Level: master/primary/
                                                                               pending assigned/pending unassigned
                                        secondary
                                                                                 Filing/Order # assigned if accepted



                              G1. BATCH PROCESS AND
                                  TRACKING AREA                                       G. NOTIFICATION STEP
                                   NOTIFICATIONS
                                                                                          Correspondence
                               Outgoing Invoice Statements                               Supplemental Items
                B.             Dishonored Payment Notices                                     Images                                           D.
                              Involuntary Dissolution Notices
                                  Annual Report Notices                                     Request Event
                                                                                                                                   If “certificate”
                                 Nighttime Lien Orders &
                                                                                                                                  correspondence
                                       Notifications                         Notification flag: pending/complete/night/void




Receipt
The 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.

Image
The 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.



                                                                                                   RFP08-1606P, SOS Information Management System, Page 29
   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.

   Notify
   As 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.




                                                    RFP08-1606P, SOS Information Management System, Page 30
State of Montana Laws and Rules
The 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-402        15-31-523      32-3-323       35-2-439       35-8-208        35-15-211      76-16-206
1-5-405        15-31-524      32-4-201 to    35-2-608       35-8-209        35-15-305      76-16-211
1-5-408        15-31-552      203            35-2-609       35-8-210        35-15-501      80-4-406
1-5-409        17-1-102       32-4-205       35-2-611       35-8-215        35-15-502      80-8-210
1-5-602 to     17-2-102       33-3-201 to    35-2-613       35-8-216        35-15-504      82-1-104
610            17-2-104       203            35-2-720       35-8-411        35-16-101      85-6-101
1-11-301       17-2-105       33-3-601       35-2-721       35-8-803        35-16-202
2-4-311 to     17-2-109       33-4-203       35-2-722       35-8-812        35-16-204
313            17-2-110       33-4-204       35-2-723       35-8-901        35-16-315
2-6-101        17-2-304       33-28-105      35-2-724       35-8-906        35-17-202
2-6-103        17-6-105       35-1-216 to    35-2-822       35-8-911        35-17-203
2-6-111        18-7-101       219            35-2-823       35-8-912        35-17-502
2-6-201        18-7-104       35-1-221       35-2-826       35-8-1003       35-17-504
2-6-202        18-7-107       35-1-229       35-2-831       35-8-1007       35-18-107
2-6-204        18-7-302       35-1-230       35-2-832       35-8-1009       35-18-201
2-6-212        19-18-102      35-1-231       35-2-833       35-8-1010       35-18-203
2-6-213        20-7-604       35-1-232       35-2-904       35-8-1011       35-18-204
2-6-405        30-9A-301      35-1-235       35-3-201       35-8-1012       35-18-205
2-15-401       30-9A-302      35-1-308 to    35-3-202       35-8-1014       35-18-206
2-15-405       30-9A-307      311            35-3-203       35-8-1201       35-18-401
7-2-4101       30-9A-420      35-1-313 to    35-3-206 to    35-8-1202       35-18-402
7-6-1539       30-9A-501 to   316            209            35-8-1210       35-18-404
7-6-1540       504            35-1-813       35-4-110       35-8-1301       35-18-501
7-6-1550       30-9A-506      35-1-814       35-4-111       35-8-1302       35-19-105
7-13-2204      30-9A-509      35-1-816       35-4-205       35-9-102        35-19-301
7-13-2214      30-9A-510 to   35-1-931       35-4-206       35-9-103        35-19-302
7-13-2215      516            35-1-933       35-4-207       35-9-302        35-19-303
7-13-2341      30-9A-518 to   35-1-934       35-4-209       35-9-401        35-19-313
7-13-2342      520            35-1-944       35-4-312       35-9-402        35-19-315
7-13-2351      30-9A-522 to   35-1-1028      35-4-411       35-10-701       35-20-103
7-13-2501      526            35-1-1029      35-4-501       35-10-703       40-5-248
7-15-2107      30-13-202 to   35-1-1031      35-4-502       35-12-505       61-12-303
7-15-2108      204            35-1-1038      35-4-503       35-12-506       69-14-501
13-10-201 to   30-13-206 to   35-1-1039      35-5-103       35-12-601       69-14-509
205            212            35-1-1104      35-5-201       35-12-602       69-14-511
13-10-208      30-13-214      35-1-1308      35-5-202       35-12-603       69-14-512
13-10-211      30-13-218      35-1-1309      35-5-203       35-12-604       69-14-551
13-10-303      30-13-221      35-1-1311      35-6-102       35-12-606       71-3-125
13-10-325      30-13-310 to   35-1-1312      35-6-103       35-12-610       71-3-203 to
13-10-327      313            35-2-213       35-6-104       35-12-611       206
13-10-404      30-13-315      35-2-214       35-8-103       35-12-612       71-3-713
13-10-405      30-13-318      35-2-225       35-8-104       35-12-613       75-6-305
13-10-501 to   32-1-107       35-2-226       35-8-108       35-12-615       76-15-213
504            32-1-301       35-2-227       35-8-201       35-12-620       76-15-214
13-10-601      32-1-371       35-2-232       35-8-202       35-12-1302 to   76-15-801
13-14-112 to   32-1-1003      35-2-305       35-8-203       1306            76-15-803
114            32-3-301       35-2-306       35-8-204       35-15-201       76-15-809
13-16-211      32-3-303       35-2-307       35-8-205       35-15-204       76-16-204
13-25-101      32-3-322       35-2-415       35-8-207       35-15-205       76-16-205

                                                  RFP08-1606P, SOS Information Management System, Page 31
ARM Codes:                             44.6.111
                                       44.6.112                               UCC-Federal Regulations:
1.2.104                                44.6.113
1.2.422                                44.6.201                               205.103
1.2.423                                44.6.202                               205.104
2.4.201                                44.6.203                               205.105
2.4.202                                44.14.101                              205.106
44.1.101                               44.14.102                              205.107
44.2.203                               44.14.301                              205.202
44.5.111                               44.14.302                              205.205
44.5.114                               44.14.303                              205.206
44.5.115                               44.14.304                              205.207
44.5.116                               44.14.305                              205.208
44.5.117                               44.14.306                              205.209
44.5.118                               44.14.307
44.5.119                               44.14.308                              Senate Bill:
44.5.120                               44.14.309
44.5.121                               44.14.310                              413
44.5.141                               44.14.311
44.5.201                               44.14.312                              Service of Process:
44.6.104                               44.15.101
44.6.104                               44.15.102                              25-20-Part II Rule 4D
44.6.108                               44.15.103
44.6.109                               44.15.105                              Title 2, Title 30, Title 13, 35 MCA
44.6.110


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.




                                                      RFP08-1606P, SOS Information Management System, Page 32
        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 level
            o 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 extended
            o Ending Balance Billing (EBB) Account - track, calculate, and assess billable order task fees that
               are “indirectly” requested by State and local government entities
            o Subscription Account – track and analyze subscription information and generate renewal
               notices
            o Dishonored Payment Account - track dishonored payment transactions, associated replacement
               payments, and/or reversal and bad debt write-off activity
            o 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-batch
            o Items Sold and Fees Due
            o Amounts Collected
            o Amounts Deposited
            o Pending Interunit Journals (IUJs)
            o Reconciliations
            o SABHRS PeopleSoft Financial Entries
      Data and Image Adjustments Tracking Area – provide options to update data and images:
            o Apply mass updates to standardize data
            o Update filing entity status or associated information
            o Annotate, add, modify, and redact images
            o Reverse and reprocess erroneous data and images
            o Update data and images to reflect uncollectible dishonored payments
            o 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 Data
            o Metadata
            o Images
            o 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.



                                                    RFP08-1606P, SOS Information Management System, Page 33
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.



                                                        RFP08-1606P, SOS Information Management System, Page 34
               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 Information
           o Deposits – Lien-Related Deposits
           o Farm Bill Information
           o Pending Imaging – Lien-Related Orders

                                                     RFP08-1606P, SOS Information Management System, Page 35
           o Public Access to Images Via Internet
           o 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


                                                      RFP08-1606P, SOS Information Management System, Page 36
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

                                                       RFP08-1606P, SOS Information Management System, Page 37
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:


                                                       RFP08-1606P, SOS Information Management System, Page 38
        Integrated Development Environment consisting of:
            o Source Code Editor
            o Compiler and/or Interpreter
            o Build Automation Tools
            o Debugger
            o Class Browser
            o Object Inspector
            o 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

                                                         RFP08-1606P, SOS Information Management System, Page 39
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 staff
             o Infrastructure software (Oracle, MS SQL, Windows Server, etc.)
             o All database server licenses required for the Development, Test, Training and Production
                systems
             o All FileNet licenses
             o SSL certificate(s)



                                                     RFP08-1606P, SOS Information Management System, Page 40
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.
 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


                                                        RFP08-1606P, SOS Information Management System, Page 41
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.

                                                           RFP08-1606P, SOS Information Management System, Page 42
      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.

                                                       RFP08-1606P, SOS Information Management System, Page 43
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.


                                                     RFP08-1606P, SOS Information Management System, Page 44
         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 failures
       2 = high
       3 = medium

                                                      RFP08-1606P, SOS Information Management System, Page 45
       4 = 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.




                                                     RFP08-1606P, SOS Information Management System, Page 46
       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.4 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.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.5 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.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.

3.4.6 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.




                                                      RFP08-1606P, SOS Information Management System, Page 47
  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).


                                                      RFP08-1606P, SOS Information Management System, Page 48
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.




                                                        RFP08-1606P, SOS Information Management System, Page 49
                                    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.

                                                        RFP08-1606P, SOS Information Management System, Page 50
      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.




                                                      RFP08-1606P, SOS Information Management System, Page 51
                               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 points
      Category                                       Section of RFP                      Point Value

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

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

A.     References                                            4.1.1                                      15
       (Complete Contact Information Provided)
                                                      RFP08-1606P, SOS Information Management System, Page 52
Company Profile and Experience                                          8% of points for a possible 120 points
     Category                                         Section of RFP                         Point Value

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

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

A.     Methods                                                4.1.3                                       30
B.     Work Plan                                              4.1.3                                       30

Financial Stability                                                                                    Pass/Fail
      Category                                        Section of RFP                            Point Value

A.     Financial Stability                                    4.1.4                                Pass/Fail

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

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

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

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

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

A.      Oral Presentation                                     4.1.7                                       50
B.      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.




                                                       RFP08-1606P, SOS Information Management System, Page 53
Cost Proposal                                                      20% of points for a possible 300 points
      Category                                       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 Points
This 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.




                                                      RFP08-1606P, SOS Information Management System, Page 54
                    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


                                                        RFP08-1606P, SOS Information Management System, Page 55
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.

                                                       RFP08-1606P, SOS Information Management System, Page 56
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




                                                      RFP08-1606P, SOS Information Management System, Page 57
              APPENDIX B: INFORMATION TECHNOLOGY CONTRACT

1.    Parties
2.    Effective Date, Duration, and Renewal
3.    Cost/Price Adjustments
4.    Services and/or Supplies
5.    Consideration/Payment
6.    Access and Retention of Records
7.    Assignment, Transfer, and Subcontracting
8.    Limitation of Liability
9.    Required Insurance
10.   Compliance with Workers‟ Compensation Act
11.   Compliance with Laws
12.   Intellectual Property/Ownership
13.   Patent and Copyright Protection
14.   Contract Performance Assurance
15.   Liquidated Damages
16.   Contract Oversight
17.   Contract Termination
18.   Event of Breach – Remedies
19.   Waiver of Breach
20.   State Personnel
21.   Contractor Personnel
22.   Meetings and Reports
23.   Contractor Performance Assessments
24.   Transition Assistance
25.   Choice of Law and Venue
26.   Scope, Amendment, and Interpretation
27.   Execution




                                                  RFP08-1606P, SOS Information Management System, Page 58
                              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.


                                                       RFP08-1606P, SOS Information Management System, Page 59
        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.


                                                        RFP08-1606P, SOS Information Management System, Page 60
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

                                                        RFP08-1606P, SOS Information Management System, Page 61
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; and
       b. 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; and
          ii. 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; or
          ii. 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; or
       d. infringement by a non-Contractor Work Product alone.




                                                      RFP08-1606P, SOS Information Management System, Page 62
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                    %

       Milestone 2:                            ___% of approved invoice                    %

       Milestone 3:                            ___% of approved invoice                    %

       Milestone 4:                            ___% of approved invoice                    %

       Milestone 5:                            ___% 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


                                                      RFP08-1606P, SOS Information Management System, Page 63
           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)

       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.

                                                       RFP08-1606P, SOS Information Management System, Page 64
       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; or
       c. 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):

                                                      RFP08-1606P, SOS Information Management System, Page 65
            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 #:

                                                      RFP08-1606P, SOS Information Management System, Page 66
            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

                                                        RFP08-1606P, SOS Information Management System, Page 67
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.




                                                        RFP08-1606P, SOS Information Management System, Page 68
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




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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:49
posted:8/23/2011
language:English
pages:69