MECL 09 - Appendix H - Uniform RFP Guide

From RCWiki
Jump to: navigation, search


MECT / MECL 2016 Documentation Toolkit
Welcome_to_MECT_2016
MECL_01_-_Medicaid_Enterprise_Certification_Life_Cycle
MECL_02_-_Appendix_A_-_MECL_and_At_a_Glance_Sheets
MECL_03_-_Appendix_B_-_Required_Artifacts_List
MECL_04_-_Appendix_C_-_Std_IV&V_Language
MECL_05_-_Appendix_D_-_Certification_Progress_Report_Template
MECL_06_-_Appendix_E_-_MMIS_Concept_of_Operations_Template
MECL_07_-_Appendix_F_-_MITA_eSelf_Assessment_Scorecard
MECL_08_-_Appendix_G_-_2007_Criteria_to_2016_Checklist_Map
MECL_09_-_Appendix_H_-_Uniform_RFP_Guide
MECL_10_-_Appendix_I_-_MMIS_Certification_Request_Letter_Template

Original File: File:09 MECT Appendix H_Uniform RFP Guide.docx

Medicaid Management Information System

Uniform Request for Proposals Guide

March 2016

Draft

Version 3.1



Preface

CMS recognizes and gives a special word of thanks to the members of The Private Sector Technology Group, the MMIS State Cohort and the MITRE Corp. for their valuable and collaborative contributions which enabled the creation of this document.


Objectives

The purpose of this document is to provide guidelines for states creating Request for Proposals (RFP) for Medicaid Management Information System (MMIS) procurement. This guide is designed to meet the following objectives:

  • Assist in streamlining the procurement process for MMIS modules, enhancements, and system replacements
  • Help reduce RFP development costs and the risk of cancelled RFP.
  • Increasing the likelihood of multiple vendor responses to ensure competitive procurements
  • Increase the likelihood of RFPs meeting CMS objectives
  • Increase the likelihood of MMIS projects achieving successful completion and system certification (on time, on budget, and with high quality)



How to Use This Guide

This guide provides an outline to develop RFPs. To truly achieve efficiencies in the procurement process, RFPs should include the sections in sequential order as outlined in the guide to streamline CMS reviews and vendor responses across states.


In general, each RFP Section includes the following:

  1. Description of Section – a high-level overview of what information should be contained in the RFP section
  2. CMS Required Language – any language that CMS requires for the RFP section
  3. Considerations/Questions to Ask Internally – Questions for states to evaluate to inform the completion of the RFP section
  4. Model Language Samples – Best practice language from published RFPs to be considered as the RFP section is completed. Multiple samples in each section are provided as alternatives, but does not imply that a state should use all options


Additional information may be included for specific sections, as applicable.


Appendices include other materials that may assist states in understanding CMS expectations related to the procurement and implementation of systems, including:

  • CMS RFP Approval Checklist –To be developed
  • Glossary of Terms and Standards



State Procurement Objectives

This section addresses the specific reasons for the procurement – what is the State looking to achieve and why now? It provides the vendors with an understanding of the motivations influencing the State’s decision to procure and insight into what the State is looking to accomplish with the procurement. It should follow a detailed description of the current environment that describes present solutions, shortcomings of those solutions, and any other motivation for proceeding with procurement. It should also describe alternative approaches the State considered and why the procurement approach was selected.


State Vision

The State vision should be clearly articulated and easy to follow. As much as feasible, the vision should be specific as it relates to the procurement in order to receive proposals most closely aligned to the State’s vision. Avoid generalized, high-level statements, as they will not positively influence system design or vision alignment.


Business Objectives

Clearly defined business objectives provide critical information to help vendors prepare their proposal.. These objectives should be closely aligned with the State vision, but should provide more concrete insight into what the State is seeking. These objectives become the framework of how a proposed solution should be designed to fulfill the State’s expectations for the new solution.



Questions to Consider Internally:

  • Is the vision clearly stated and relevant to this procurement?
  • Do the business objectives outline the procurement goals clearly?
  • Do the vision and business objectives support the Seven Conditions and Standards and the MITA framework?
  • Do the business objectives support compliance with the MMIS certification criteria?


Technology Standards

CMS Requirements

Alignment with Seven Conditions and Standards

To achieve an improvement in the procurement process, it is essential for States to understand and align technology procurements with the “Seven Conditions and Standards” as originally outlined in April of 2011, with complementary definition provided by the NPRM, released in April 2015. This is an important baseline for any Medicaid System Modernization. The Seven Conditions and Standards are:

  1. Modularity Standard – This condition requires the use of a modular, flexible approach to systems development, including the use of open interfaces and exposed application programming interfaces (API); the separation of business rules from core programming; and the availability of business rules in both human and machine-readable formats. The commitment to formal system development methodology and open, reusable system architecture is extremely important in order to ensure that states can more easily change and maintain systems, as well as integrate and interoperate with a clinical and administrative ecosystem designed to deliver person-centric services and benefits.

Modularity is breaking down systems requirements into component parts. Extremely complex systems can be developed as part of a service-oriented architecture (SOA). Modularity also helps address the challenges of customization. Baseline web services and capabilities can be developed for and used by anyone, with exceptions for specific business processes handled by a separate module that interoperates with the baseline modules. With modularity, changes can be made independently to the baseline capabilities without affecting how the extension works. By doing so, the design ensures that future iterations of software can be deployed without breaking custom functionality.

A critical element of compliance with this condition is providing CMS with an understanding of where services and code will be tightly coupled, and where the state will pursue a more aggressive decoupling strategy.

RFP HELPFUL HINT: To demonstrate the state’s approach to the Modularity Standard, the state should define, within the RFP, which components/functions of the MMIS will be procured as discrete modules, a strategy for how these modules will be integrated (i.e. System Integrator vendor), and how changes should be managed to ensure the integrity of ‘modular independence’ during the maintenance and operations period.


  1. MITA Condition – This condition requires states to align to and advance increasingly in MITA maturity for business, architecture, and data. CMS expects the states to complete and continue to make measurable progress in implementing their MITA roadmaps. Already the MITA investments by federal, state, and private partners have allowed us to make important incremental improvements to share data and reuse business models, applications, and components. CMS strives, however, to build on and accelerate the modernization of the Medicaid enterprise that has thus far been achieved.

RFP HELPFUL HINT: States should share, as part of the RFP, or as part of a Bidders’ Library, the MITA Maturity Model Roadmap from the MITA 3.0 State Self-Assessment (SS-A), provided to CMS as part of the APD process. This document will be updated on an annual basis. States should require as part of the RFP that vendors demonstrate how the proposed solution(s) improve the State’s MITA maturity defined in the Roadmap. Additionally, States should consider, when sequencing modular implementation/replacement, that the procurement includes a sequencing plan that considers cost, benefit, schedule, and risk.

States should also share as part of the RFP, or as part of a Bidders’ Library, a concept of operations and business work flows (developed as part of the MITA 3.0 SS-A) for the different business functions of the state to advance the alignment of the state’s capability maturity with the MITA Maturity Model (MMM). As a reminder, States should work to streamline and standardize these operational approaches and business work flows to minimize or eliminate customization demands on technology solutions and optimize business outcomes.


  1. Industry Standards Condition – This condition requires States to ensure alignment with, and incorporation of, industry standards: the Health Insurance Portability and Accountability Act of 1996 (HIPAA) security, privacy and transaction standards; accessibility standards established under section 508 of the Rehabilitation Act, or standards that provide greater accessibility for individuals with disabilities, and compliance with federal civil rights laws; standards adopted by the Secretary under section 1104 of the Affordable Care Act; and standards and protocols adopted by the Secretary under section 1561 of the Affordable Care Act.

CMS must ensure that Medicaid infrastructure and information system investments are made with the assurance that timely and reliable adoption of industry standards and productive use of those standards are part of the investments. Industry standards promote reuse, data exchange, and reduction of administrative burden on patients, providers, and applicants.

RFP HELPFUL HINT: The state must identify all industry standards relevant to the scope and purpose of the project and produce development and testing plans to ensure full compliance. States must also have risk and mitigation strategies in place to address potential failures to comply.

The RFP should ask vendors to specify how the proposed solution(s) comply with applicable standards identified by the State, including best practices of the U.S. Digital Services Playbook (https://playbook.cio.gov/ ), and how compliance can be verified during DDI and maintained during the Operations Phase.


  1. Leverage Condition – Promotes solution sharing, leverage, and reuse of Medicaid technologies and systems within and among states. States can benefit substantially from the experience and investments of other states through the reuse of components and technologies already developed, consistent with a service-oriented architecture, from publicly available or commercially sold components and products, and from the use of cloud technologies to share infrastructure and applications.


RFP HELPFUL HINT: For the Alternatives Analysis completed as part of producing the Advanced Planning Document (APD) to secure enhanced funding, States should consider existing state systems and infrastructure that may be leveraged, other states’ systems and services, commercially sold components and products, and the use of cloud technologies. The RFP should identify existing state systems that will be leveraged, how they will be leveraged, and encourage bidders to propose alternative solutions that demonstrate reuse of developed technologies available in the Health IT marketplace that are configurable to meet the States’ requirements. Where a state selects to use a commercially sold component or product, or to reuse another state’s provided system, the RFP should provide descriptive detail, and encourage bidders to identify how they would approach integration.


  1. Business Results Condition – Systems should support accurate and timely processing of claims (including claims of eligibility), adjudications, and effective communications with providers, beneficiaries, and the public. The degree of automation of business functions, the end-user and customer service experience, and measured service levels are factors to assess as part of measuring the effectiveness of the solution(s).

Ultimately, an effective and efficient system supports and enables an effective and efficient business process, producing and communicating the intended operational results with a high degree of reliability and accuracy.

RFP HELPFUL HINT: The RFP should describe the business processes the system and/or services being procured must support, including the Key Performance Indicators and the Service Level Agreements (SLAs) that will be used to measure outcomes to determine if successful outcomes are achieved.


  1. Reporting Condition – Solutions should produce transaction data, reports, and performance information that would contribute to program evaluation, continuous improvement in business operations, and transparency and accountability.

RFP HELPFUL HINT: States can leverage the data information architecture component of the State’s MITA 3.0 SS-A to define business requirements that support the Reporting Condition. Systems should be able to produce, and to expose electronically, the accurate data that are necessary for oversight, administration, evaluation, integrity, and transparency. Reporting requirements include necessary federal reports (including program development and operations performance metrics), system transaction audit trails, MARS reports, Program Integrity (SURS), financial transactions and management reports, waiver reports, and any state specific reporting requirements for the effective and efficient program management and to promote effective customer service and better clinical management and health services to beneficiaries.


  1. Interoperability Condition – Systems must ensure seamless coordination and integration across applicable state and federal systems, including Eligibility, Medicaid systems, Health Insurance Marketplaces, Health Information Exchanges. As well as allow interoperability with public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services.

RFP HELPFUL HINT: The RFP must articulate requirements that systems are built with the appropriate architecture and use standardized messaging and communication protocols in order to preserve the ability to efficiently, effectively, and appropriately exchange data with other participants in the health and human services enterprise. States should require as part of the RFP that vendors demonstrate how integration and interoperability will be achieved between existing systems and new modules and system components that are implemented as a state-built solution, COTS, or as reused from another state’s provided solution.


Alignment with Other Conditions for Enhanced FFP for the Design, Development, Installation, or Enhancement of an MMIS

To qualify for 90 percent Federal Financial Participation (FFP) for State expenditures for the design, development, installation, or enhancement of an MMIS, a State must also ensure that the RFP is consistent with procurement and system requirements described in 42 CFR 433.112(b)(1) through (b)(9). Requirements in 42 CFR 433.112(b)(10) through (b)(16) are described above under “Alignment with Seven Conditions and Standards”.

State Technology Standards

OPTIONAL section: for states to insert state-specific technology requirements language and discuss ownership, (consult ownership considerations as identified in the April 2015 NPRM) of software and other contracting considerations.


Scope of Work

This section defines the tasks, activities and requirements (functional, technical, and operational) to be performed during the period of performance. This is a core component of the RFP agreement between the procuring agency and the selected vendor.


Detailed requirements should describe what the State desires and required service levels. The vendors responding to the RFP should describe how the proposed solution (and staffing model) meets these requirements. To open competition and innovation, allow vendors to use their expert judgment to propose their model of how to complete the work.


The following defines types of requirements that may be included in the scope of work:

  • Business Requirement (BR) – A BR is a statement of the functions needed in order to accomplish the business objectives. It is the highest level of requirement, developed through the dictation of policy and process by the business owner.
  • Functional Requirement (FR) – An FR is a statement of an action or expectation of what the system will take or do. It is measured by concrete means like data values, decision making logic and algorithms.
  • Nonfunctional Requirement (NR) – An NR is a technical requirement that focuses on the specific characteristics that must be addressed in order to be acceptable as an end product. NRs have a focus on messaging, security, system performance, and system interaction.


Sample language in this section should require that the replacement of the legacy MMIS shall be through an integration of existing and proven solutions that demonstrate modularity, with limited custom development (within each modular component), conformance to MITA principles, the CMS Seven Conditions and Standards, and achieve CMS certification. States should consider including a requirement that the vendor will work with and support the state’s procured IV&V contractor. Additionally, states should consider including a requirement that the vendor will support the state in preparation and support for certification life cycle gate reviews held between the state and CMS.


In order to maximize sharing of available components, the system integrator must be empowered, not limited. In order to do so, it may be necessary for the system integrator to do a great deal of development and configuration: to design and implement modules, system components, data definitions, and module interfaces using IT techniques enabling reuse and interoperability; and to design and implement inter-module/system interfaces, with data translation as needed to support integration and interoperability with existing interfaces; and, to design and implement data and business rule conversion, as necessary, to enable reuse of and integration with an existing module.


Additionally, it is a best-practice to include CMS Certification requirements applicable to the system or system component(s) being procured.


Within any RFP, the following High Level items must be addressed, as identified in Chapter 11 of the State Medicaid Manual:

Statement of the purpose and scope of the specific work and/or services to be performed including a period of performance within which you expect to have the work performed;

Listing and description of the reference material available to the contractor for use in preparation of proposals and/or in performance of the contract;

Statement of contract termination procedures;

Standard format and organization for the proposals including both work to be performed and cost statements;

Explanation of the proposal evaluation criteria and the relative importance of cost or price, technical, and other factors for purposes of proposal evaluation and contract award;

Description of the nature and extent of involvement of Medicaid agency personnel during the contract, including the name and title of the project officer;

Description of the supplies, clerical support, computer time, work space, etc., that will be made available by the State, if applicable;

Statement that the prime contractor is responsible for contract performance, whether or not subcontractors are used;

Requirement that the contractor's personnel resources to be assigned to the contract are identified;

Requirement for a schedule of proposed work (work statement), including well defined milestones;

Requirement for a breakout of the total cost to perform the contract including the costs for individual phases or areas of the work statement;

Requirement for a statement of corporate financial stability and/or for a performance bond; and

  • Statement that the proposed contract will include provisions for retention of all ownership rights to the software by the State, if designed, developed, installed, or enhanced with FFP. (See 42 CFR 433.112 (b)(5) and (6), and 45 CFR 95.617(a)).”
  • Advanced Planning Document Checklist

Questions to Consider Internally:

  • Does the RFP show how the system must ensure seamless coordination and integration with the Eligibility Determination System, and allow interoperability with health information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services?
  • Is the Medicaid Enterprise promoting the sharing, leveraging, and reuse of Medicaid technologies and systems within and among States?
  • Does the RFP show how the system must support accurate and timely processing of claims (including claims of eligibility), adjudications, and effective communications with providers, beneficiaries, and the public? Does the RFP show how the system must produce transaction data, reports, and performance information that would contribute to program monitoring and evaluation, continuous improvement in business operations, meeting established Key Performance Indicators, and transparency and accountability?
  • Based on the number and complexity of requirements and deliverables specified in the RFP, does the state have sufficient staff dedicated to the project to review and approve them? Are the deliverables required truly relevant to our success and not just “shelf files”? If the State is not able to review deliverables timely, the overall project schedule will suffer.
  • Is the DDI methodology too structured or prescriptive that the State may not benefit from a vendor’s proven processes, tools, and procedures?
  • Is the workplan to be submitted in the proposal outlined in enough detail to provide the State a good basis to build onto when the contract is awarded?
  • Has the State provided enough detail so that a vendor can adequately scope integration points and be successful?
  • For carved out services, i.e., provider credentialing, DSS, pharmacy rebate, care/case management, is there a clear delineation of services so that requirements defined in this procurement do not overlap with requirements that are part of another vendor’s contract?
  • If we are moving into a managed care model or already in a managed care arrangement, has the State asked for the “right” services, i.e., MCO performance analytics, relevant claims processing for just the remaining fee for service population?
  • When creating the timeline, does the State provide a sufficient period of time to allow both the vendor and State staff to prepare for the implementation period, as well as ensuring all of the State staff are prepared for the extensive implementation activities?


Questions to Consider Internally:

  • Do the requirements define “what” the State needs without specifying “how” the requirement must be met? Requirements that prescribe the exact method for how they are to be met may prevent vendors from leveraging the capabilities of their solutions and may require custom development, increasing the cost to the State without increasing value.
  • Are the implementation and operation phases and the expectations for each phase clearly defined? Consider specifying exit criteria for each phase to define specifically the conditions that must be met for that phase to be determined complete.
  • Is each requirement listed only once in the Statement of Work, or are some repeated in various sections of the RFP? Repeating requirements forces vendors to provide the same response multiple times and also requires the State evaluators to review those repetitive responses. For requirements that apply to multiple functional or programmatic areas, consider utilizing cross-references to ensure all relevant areas are addressed in a single response.
  • Has sufficient evaluation of COTS or modules intended for use been performed against the State’s business processes, functional requirements, and IT infrastructure to confirm that integration of the COTS or module will require only configuration and not customization?



Cost Model and Budgeting Specifications

This section addresses the cost model and budgeting specifications within the RFP. It provides guidance to vendors in terms of the type of procurement that the State is considering in the project phase (DDI), and the alignment of operational cost model goals to the State’s Medicaid vision. The goal of this portion of the procurement is to promote competition, obtain best value in terms of cost and deliverable.

, and maximize the likelihood of RFP award, and project success.


Questions to Consider Internally:

  • Has the State considered value and performance based pricing models? The incentive aspects of value-based pricing offer States with an effective tool that rewards vendor creativity, innovation, and “extra effort.” The most rewarding concepts for value-based pricing include pricing models offering additional revenue-generating opportunities or the potential for cost savings or cost avoidance. To realize the financial rewards associated with a value-based model, the contract terms must include performance metrics as well as the formulas used to achieve an incentive payment. When employing this model, it is also important to develop an incentive payment structure that aligns to pre-defined levels or performance tiers. When contracts include performance tiers, the contractor is incentivized to do more than meet minimum contract requirements. Performance tiers must encourage contractor behavior to explore innovative solutions in order to reap the financial rewards associated with this model.
  • Has the State considered including a limited pool of hours for use during DDI to cover changes/enhancements? This would require vendors to price optional additional resource costs in the proposal by labor category to be deployed only after review and approval by the change control board and the State’s project manager. This pre-established pool of hours with established rates provides CMS-approved hours for scope management if needed.
  • Has the State considered transaction pricing above a minimum to be included in fixed price? Such transaction pricing could allow for a single amount per transaction above. the minimum, or the State could establish multiple tiers if there is the potential for wide variation. Examples include:

• Claims processed

• State -initiated adjustments processed

• Provider enrollments/re-certifications

• Prior approvals processed




Project Management and Governance

This section provides guidance regarding the project management and governance aspects of the project, the state resources available for these activities, and the state governance model as it relates to the project and MMIS operations.


  1. State Project Governance

Define the state’s project governance structure including project key staff assigned and the respective roles on the project. Also define the escalation path for resolving risks and issues, levels of responsibility for oversight of the project and project resources dedicated to support the project.


  1. Vendor Project Management

This subsection should include requirements for how the vendor needs to demonstrate how they will manage the project; include language around working with other prime vendors and IV&V contractor. If this effort requires the successful contractor to collaborate in any way, or cooperate with, another contractor, the State should require the contractor to create/execute an associate contractor agreement. [Address the subject of proprietary software by the subcontractors, by the SI and the State.]



Questions to Consider Internally:

  • Are there State standards for project management or templates that are required by procurement law to be incorporated into the project? Ask vendors to propose the standard project management methodology and existing project management documentation they utilize to implement the solution being proposed. Consider identifying in the RFP key State personnel (positions, not names), committed to the implementation project such as business and operations informational, technical and systems, hierarchy of approval and resolution of issues, etc.
  • What additional staffing (outside of the vendor staff) is essential for success? Consider any personnel from other State departments/divisions/agencies; other stakeholders; other business partners; independent contractors and suppliers of services (for example, IV&V, Quality Assurance, auditors, etc.) that are integral to the project.
  • Are there any possible gaps in State staffing for the project? If so, determine how and who will fill in the gaps.
  • How will issues and risks be escalated, when, and to whom? Identify any requirements for project management reporting, status meetings, executive level meetings or other project management coordination and reporting mechanism.
  • What information and what level of detail is required for the project schedule submitted with the proposal? How often will the project schedule be updated?
  • How will the State’s program management office obtain situational awareness of each project’s status, and with this information, make decisions and take effective action across the projects?
  • How will the State’s program management office monitor vendor compliance to state standards and to the Digital Playbook, during DDI and while in operations?
  • How will the State’s project management align its release schedule with that of COTS vendors, who will each have their own feature roadmap?
  • How will the State’s project management monitor vendor effort applied to COTS integration versus customization?


Key Personnel

This section provides guidance regarding proposed Key Personnel. When developing the RFP, consideration should be given to matching qualifications to needs, ensuring availability of key staff when required and that the number sought is actually needed, as well as whether and where there could be flexibility and defined procedures surrounding such flexibility. It is possible that competition can increase and costs be reduced when there is the appropriate balance between ensuring the state’s needs are met without becoming too prescriptive.


Thoughtful review of the business, informational, technical, and operational needs, processes, and goals during the very first stages and throughout the project will set the state on a path to acquiring the key personnel, with the best qualifications, at the time in the project when they are needed.


CMS does not require specific language in RFPs to address vendor key personnel. The only direct reference to such is contained in the State Medicaid Manual, Section 11266, bullet point 9, which states the following:

The RFP must include at a minimum:

  • Requirement that the contractor's personnel resources to be assigned to the contract are identified;”

Questions to Consider Internally:

  • What vendor(s) key personnel are essential for success? When the project includes multiple vendors, consider the timing and coordination of key personnel for each vendor as well as any required coordination among the vendors, State, and other stakeholders.
  • What are the specific qualifications for the key personnel needed for the actual scope and purpose of the project(s) within this RFP? What are the definitive, essential requirements for the key personnel? Consider allowing vendors to define staff requirements commensurate with the vendor’s implementation and operation methods (this may be informed by State procurement rules).
  • Is the number and qualifications of key personnel reflective of the project’s scope? Does the number match what is essential for the project? Is the number reflective of the State’s and other project partners’ total staffing and expertise for the project? Consider limiting named key staff to the positions relevant for implementation (elevate operations -related positions to ‘key’ at a designated period prior to deployment).

At the first stages of consideration of the project, while reviewing the business, informational, and technical needs, processes, and goals within the scope of the project, has the State considered the following:


  • Has the State considered flexibility in RFP-defined qualifications which could promote the best pool of candidates? Would the State allow named key staff to offset college degree requirements with comparable job experience based upon Department of Labor or some other defined guidelines? This could result in more consistent and competitive bids from all vendors and a larger pool of qualified candidates. For example, the NY Proposal allowed at least two or four years of specified experience in lieu of a degree for various key positions.
  • When asking for individual resumes and related information, has the State considered at what stage(s) of the project each of the vendor’s key personnel is required; for example, operations? For those key personnel not required during the initial stages of the project, consider specifying alternatives for when and how the winning vendor would propose such key personnel. This would allow consideration, review, and selection of candidates closer to the stage when such key personnel are needed; thereby, providing more up-to-date selection options and reducing the risk that named key staff are no longer available when needed. For example:
    • Require vendors to submit “sample resumes” for such delayed key positions, with actual candidates submitted prior to the stage when the position is required. State approval would be required for proposed candidates. For example, the NY MMIS RFP specified that the Transition Manager name and resume was not requested for bidders’ proposal and the position did not need to be available at the contract start date.
    • Allow a process to modify requirements for such key personnel, based on what has been learned in the project to date.
  • What requirements for location of staffing, including key personnel, have been specified in the RFP? Consider that during DDI, a cost-effective approach is to allow much of the DDI/configuration work to be done in a vendor’s onshore centralized location rather than requiring all work to be done onsite. If the vendor is following Scrum development methodology, it would be appropriate for the vendor’s location to be near the State’s business and project leaders.
  • What procedures have been prescribed in the RFP to ensure any change(s) in key personnel during the project meet the State’s needs?







Project Performance Standards

The section outlines the project performance standards for all phases of the project as well as any associated penalties or damages, as applicable. Major considerations in this section include identification of the critical measures of successful project performance and how incentives or penalties can be used to ensure that performance standards are achieved and maintained throughout the project. As a guide, performance standards should be:

  • Focused on the results most important to the success of the project
  • Clear
  • Concise
  • Unambiguous
  • Measurable
  • Reasonable/Attainable
  • Not overly punitive or duplicative
  • Appropriate for:
    • The services being provided
    • This specific type of contract (performance-based, fixed-price, deliverables-based)


Questions to Consider Internally:

  • What performance standards are applicable and desired for the DDI period? Which apply during Operations? Clearly delineate performance expectations and standards applicable to each phase of contract performance.
  • Are the SLAs that we established measurable? Do they address the points that are the most important to the overall health of our contract and system?
  • Are penalties or incentives to be included as a part of the contract? If so, what are they? What is the structure and process for imposing? Identifying any dollar amounts in the RFP allows vendors to understand the full financial picture and risks within the project and to price them accordingly. As outlined in Section 8, Contract Standards, providing a mechanism for vendors to take exception or propose modification allows for negotiation while providing an even playing field for all bidders.
  • Assemble all performance standards in a single location in the RFP for ease of reference and evaluation and to ensure that all requirements are spelled out and understood.
  • Specific considerations/questions for the operations period:
    • What is most important to the State? What is the protection being sought? Performance standards, or SLAs, are most effective when limited to only those items critical to the success of a state Medicaid program and the benefit of its stakeholders. Fewer than 20 performance standards/SLAs can typically achieve this goal. Consider placing a monthly cap on SLA penalties and/or waiving SLAs for a period of time immediately after the new system goes live to allow for a stabilization period.



Contract Standards

This section provides information regarding the nature of the contract to be executed as a part of the procurement. It is recommended that States provide all contract terms and conditions which are anticipated to be included in any resulting contract as a part of the procurement process. This includes standard terms and conditions, CMS regulations. This can be achieved by including a sample contract from the State’s Procurement Office.


The following items must be covered, as identified in Chapter 11 of the State Medicaid Manual:

  • Statement of contract termination procedures;
  • Statement that the prime contractor is responsible for contract performance, whether or not subcontractors are used;
  • Requirement for a statement of corporate financial stability and/or for a performance bond; and
  • Statement that the proposed contract will include provisions for retention of all ownership rights to the software by the State, if designed, developed, installed, or enhanced with FFP. (See 42 CFR 433.112 (b)(5) and (6), and 45 CFR 95.617(a)).”

Depending on the contract, other requirements identified under 42 CFR 434 (Contracts) may also apply.


Questions to Consider Internally:

  • What terms and conditions are applicable based on the nature of the services/system being procured? Contractual language should be reasonable based on project size, scope, and purpose. Items such as actual damages, liquidated damages, performance and bid bonds, SLAs, payment retention, and general contract terms should protect the State and vendor.
  • Identify those contract terms and conditions which are non-negotiable and permit vendors to provide comments or take exceptions on other terms. Submission of any exceptions or concerns with the proposal will allow the State to assess whether or not a contract is likely to result with a bidder. Due to the complexity of MMIS contracts, a final contract negotiation provides for an agreement that works best for the specific partnership between the State and selected vendor. As a part of the negotiations, assess which items are of most importance to protect the State and avoid treating every term of equal importance.
  • Is a bid or performance bond required by procurement law? If not required, consider whether or not the amount being requested is appropriate for the nature of the work and will actually provide the protection sought by the inclusion of a bond. Unreasonably high bonds can limit competition and inflate costs without providing the State with additional protection.
  • Is a payment retention or holdback required by procurement law? If included, what is the appropriate amount to protect the State? Consider alternatives through the payment structure to avoid holdbacks which can inflate prices through vendors including costs of financing in their pricing and can create performance risks during contract execution.
  • Are the software license requirements consistent with standard practices in the software industry as well as with the nature of the system/services being procured? As there is an effort to move to more COTS-based and Software-as-a-Service solutions, requiring vendors to sign non-negotiable or proprietary licensing agreements often precludes competition as product vendors cannot sign up to the required conditions. Starting with end-user license agreements (EULA) provided by software vendors creates a more commercially acceptable RFP open to compliance.
  • Can the contract be extended to include other State agencies/programs? Consider that many states have expanded use of their MMIS to support other programs (i.e., corrections.)
  • If developed software or IT solution is intended for sharing with other states, does the contract and software licensing support this State intent?
  • If the State intends to reuse developed software or an IT solution shared by another state, does the contract and software licensing support this State intent?



State Procurement Process

This section provides the guidelines under which the procurement will be conducted. It outlines the rules regarding contact and communication with the State, the overall timeline for the procurement including applicable due dates for materials, the process for submitting questions, identifies appropriate state procurement requirements and often includes the submission requirements.


This section is critical to a successful procurement process by establishing a common, unbiased framework for all vendors participating in the process. It is critical that all applicable procurement regulations be incorporated and understood when structuring this section. It establishes clear expectations for all vendors to ensure a fair process and reduces the risk of procurement protests.


Other elements of the procurement process may not be included in the specific Procurement Process or Instructions section but may be reflected in the Evaluation Criteria.

CMS Required Language

As outlined in Section 2, Chapter 11 of the State Medicaid Manual includes the following items:

  • Listing and description of the reference material available to the contractor for use in preparation of proposals and/or in performance of the contract;
  • Standard format and organization for the proposals including both work to be performed and cost statements;
  • Explanation of the proposal evaluation criteria and the relative importance of cost or price, technical, and other factors for purposes of proposal evaluation and contract award;

There are many considerations and questions to consider when structuring the overall procurement process. The questions below assume that the State has already determined the scope of services to be procured and are focused more on the process itself. A thorough understanding of procurement law in the State and what is and is not permissible within the procurement guidelines is critical to structuring the overall process. Coordination between the business/program team and the procurement organization or department will facilitate the overall process by aligning the business needs to be met and structuring the procurement process to help ensure those needs will be addressed in the procurement. Some considerations are outlined below:




Questions to Consider Internally:

  • Do the procurement guidelines permit an RFI or draft RFP process? If so, before undertaking either, consider:
  • What is the goal of using either approach? For example:
    • Solicit feedback or input on the proposed project scope and structure
    • Gain input on alternative approaches to meet the business need
    • Gather information on what is currently available in the market
    • Identify any portions of the RFP that may limit the number of vendors that respond
  • Does the State want vendor demonstrations as a part of the procurement process?



  • Assess what information is needed from vendors and streamline the response structure to avoid submission of duplicative information. By associating the requested information with the evaluation criteria, vendors are allowed to focus on what is of most importance to the State, resulting in responses that are easier for evaluators to assess against the State business needs that are to be met through procurement.
  • Do you want to limit the number of pages in the responses overall or for some sections of the response? Identify realistic page limitations according to response structure and specify those sections excluded from page limits. Anticipated page limits should be included in a draft RFP for vendor comment.
  • Is the RFP clear in how you expect vendors to reply to requirements listed in the SOW in relation to Functional, Technical, and Fiscal Agent requirements included in attachments (MECT checklist, etc.)? Consider how to help ensure vendors understand how to address the SOW so as not to duplicate responses and overtax or confuse reviewers. Don’t be vague: If vendors are to write to the Scope of Work AND the requirements listed in, say, the Functional Requirements section of an RFP, say so.
  • Based on how the State has defined the evaluation criteria, is the scoring aligned with what is being asked for in the proposal response and does the scoring methodology reflect a weighting that demonstrates what is most important to the State?
  • Have the points been appropriately divided between technical approach and costs (when applicable) to select the best value solution? Or does the scoring result in the ‘lowest price wins’?
  • Are there multiple ongoing procurements related to the system or services being procured occurring in other States at the same time? This should be considered when assessing the overall time to release and respond to RFPs.
  • Considering State resource availability, what is a realistic timeline for the procurement process? It is best to not try and work backwards from a ‘we must award by’ date which can set unrealistic expectations with both internal and external stakeholders. Other timeline considerations include a decision on permitting multiple rounds of questions/answers during the process as well as determining if a rolling question/answer period will be used. Permitting multiple rounds of questions and setting a realistic timeline for submission of questions allows vendors to perform a more thorough analysis of the RFP and identify questions or concerns, resulting in a higher quality offering/solution and a higher probability of overall successful project execution.
  • Does the State envision including system demonstrations or oral presentations as a part of the procurement process? Including the guidelines for this in the RFP as well as ensuring adequate time for State activities between proposal submission and scheduling of the events in the procurement timeline provides a level playing field and adequate time for preparation on both sides.
  • If including demonstrations or oral presentations, will these be held before or after proposal review and evaluation? How will they be factored into evaluations – separately scored or as a part of the technical evaluation score?
  • What are the preferred (and permissible) forms of proposal submission? Is a predominately electronic submission permissible? If paper/hard copy submissions are required, how many are needed? It is worth considering that, for many people, electronic submissions are easier to review and evaluate recognizing that a small number of hard/paper copies may be required for contractual/legal purposes.
  • What materials are available or can be assembled to form the procurement library? Material could include items such as historical performance and trend data, MITA State Self-Assessment (SS-A) results, the APD, internal and external interfaces, operations volumes (i.e., claims, prior authorizations, providers, members by program, etc.) and State staffing models. Providing this library of information allows questions and strategies to be developed, which results in a more competitive procurement and allows vendors to prepare more comprehensive responses.





Appendix 1 – Model Language Samples

State Procurement Objectives

The following are examples in recent MMIS procurements for vision and business objectives that provide clear pictures of the vision and objectives for the procurement. Please note that use of the term “objectives” is often used to articulate the overall vision, and the term “goal” is often used to define specific business objectives.


State Vision


Example 1: The goal of this procurement is to obtain a Replacement MMIS that has the information infrastructure, tools, and services necessary to efficiently administer the [State Medicaid] programs, and other programs in the [State Medicaid Enterprise] supported by the MMIS, to improve member health outcomes, and assist in the delivery of member-centric and cost effective care in an environment of dynamic health care system transformation. It will have the capabilities to promote informed and timely decision-making, both at the policy administration level and at the point of care, while promoting service coordination, transparency, and accountability.


The Replacement MMIS will:

  • be the information gateway for all stakeholders;
  • take advantage of automation and paperless transactions;
  • facilitate data access and exchange in real-time while ensuring privacy and security; and
  • be designed to accommodate current and future business methods.

Data in disparate systems will be integrated to reduce redundancy and compartmentalization, improve information exchange, and services will be shared to ensure data accuracy and validity.

(Source: New Jersey Request for Proposals 14-X-22996, 2013)


Example 2: With this RFP, [State] seeks to procure a modular MMIS, as well as a FA and/or a system integrator to support some or all of the MMIS. Following are [State’s] goals for the modular MMIS:

  • Provide information management tools and business partners to assist [State and/or Agency name that owns the contract] in effectively managing the State Medicaid program
  • Support monitoring the performance of [Medicaid Program Name] MCOs
  • Use a modular approach to create a framework that is aligned with MITA Version 3.0 and supported by a Service-Oriented Architecture (SOA) and unified data governance. [State and/or Agency name that owns the contract] expects this modular approach to result in low-risk MMIS compliance and more efficient customer service
  • Meet the CMS 7C&S and promote the use of industry standards for information exchange and interoperability, providing a seamless business services environment for [State and/or Agency name that owns the contract] users
  • Supports the State in maintaining eligibility for FFP for the design, development, installation, and enhancement of mechanized claims processing and information retrieval system as specified under 42 CFR 433.112 by proposing a modernized system which meets the conditions within the federal regulation.

(Source: Kansas Request For Proposals EVT0003406,2014)


Example 3: The Agency’s objective for this procurement is to maintain the current business model of the cohesive [State or Agency that owns the contract] with “best-of-breed” contractors co-located with Agency staff at a common facility. Co-location of Agency staff and [State or Agency that owns the contract] contractors will continue to yield significant efficiencies for the IME, allowing the Agency to continue to provide a highly effective level of service for both members and providers alike. The [State or Agency that owns the contract] is not unlike the conceptual view of the operation of a managed care organization (MCO) or health maintenance organization (HMO). This strategy allows the state to retain greater responsibility for the operation and direction of healthcare delivery to Medicaid members in [State].

(Source: Iowa Medicaid Enterprise System and Services Request for Proposals, 2013)


Example 4: The Department’s vision for managing public health care encompasses the following goals and objectives:


Reduce Administrative

Burden for the Provider

The Department is committed to making changes that will make it easier for health care providers to enroll, participate, and be reimbursed in its programs. The Department is taking steps to streamline the enrollment process through the adoption of standards, alignment with other programs, and automation of processes. A main objective in this area is to simplify the combination of program, policy and operational constraints to payment.

Eliminate Administrative

Barriers to Enrollment and

Expand Coverage

One of the key health care initiatives of the current administration is to expand health care coverage to all eligible New Yorkers. The Department has a goal to remove administrative barriers that delay and prevent some eligible citizens from receiving health care benefits. The objective is to identify and make changes to administrative processes that are used to determine eligibility and to support the implementation of Federal health care reform.

Accommodate Benefit

Flexibility to Provide

Member Services

The capability to accommodate new benefits, service rules, and edits into operations and systems quickly is a critical component to realizing the vision to effectively align program benefits with beneficiaries. Inherent in this endeavor is the need to share clinical information at the point-of-service to enable the identification of beneficiaries for new benefit programs and to better manage high need and high cost services. The introduction of COTS products is critical to developing the capability to implement software and procedural enhancements in a timely and cost effective manner.

Buy value – quality, cost effective care – for Medicaid beneficiaries

The Department envisions the development of patient centric health care delivery programs that will provide quality, cost effective health care. This will begin to be achieved as the Department moves to predictive modeling, patient centric utilization management, care and case management, the adoption of a medical home model, and increasing patient education and counseling.

Integrate Electronic Health Care Records into Benefit Management

The electronic exchange of health care information is the centerpiece for realizing a number of health care management improvements. The ability to share detail clinical information at the point-of-service is at the center of a new generation of health care programs that effectively match the right services with the right people at the right time.

Implement Medicaid Rate Reform – Pay for Performance

The Department has taken the initial steps in developing Pay for Performance initiatives which link compensation to the quality of outcomes, standardized quality measures or the extent to which specific goals are achieved. The Department understands that in order to continue to create and effectively evaluate Pay for Performance outcomes, more specific clinical data is needed. The Department envisions reforming Medicaid rates to: encourage care in the right setting; buy value and high quality, cost effective care; and, reinforce health planning and policy priorities.

(Source: New York Request for Proposals. Replacement Medicaid Management Information System (R-MMIS) Fiscal Agent Services Project FAU Number 1002031048, 2010)


Business Objectives


Example 1: Critical technological objectives of this RFP include the procurement of:


  1. A true Service Oriented Architecture (SOA) platform which will bring interoperability of service-based modules, preferably as licensed products, to support DHS’ modernization and continual enterprise evolution without restricting its ever-changing business needs
  2. A highly configurable and flexible platform that will be an enabler of the expansion of technological capabilities to other state and federal agencies
  3. An enterprise solution that is designed at its core to allow Commercial-Off-The-Shelf(COTS) products be installed, integrated, and upgraded through scheduled releases
  4. Software modules that are implemented and modified by user configurations, not through constant custom coding that will result in yet another one-off MMIS


(Source: Arkansas Request For Proposals, AME MMIS Core System and Services, 2013)


Example 2: The State considers this RFP as foundational to the State’s transformation of the Medicaid enterprise. The Key Objectives are defined in Table 1. The State encourages the Contractor to periodically reference the Key Objectives and to utilize the information located in this RFP’s Resource Library to enhance the Contractor’s Proposal response.


Table 1
Key Objectives

Identifier

Description

T1.1

Deliver the Centers for Medicare & Medicaid Services (CMS) criteria defined in the

Medicaid Enterprise Certification Toolkit (MECT) v 2.01

T1.2

Leverage where appropriate the State’s existing investments in information technology, systems and services, and third-party relationships operating as part of the Medicaid enterprise

T1.3

Comply with the CMS Seven Standards and Conditions released April, 2011

T1.4

Advance the organizational productivity and analytical capabilities of the Medicaid enterprise to promote cost reduction and MITA process maturity

T1.5

Support the advancement of payment reform methodologies

T1.6

Participate in the State’s Medicaid domain information exchange goals

T1.7

Deliver the Project in accordance with the Contractor’s contractual obligations

T1.8

Support Arkansas’ business process improvement objectives as defined in its MITA State Self-Assessment (SS-A).

(Source: Arkansas Request For Proposals, AME MMIS Core System and Services, 2013)


Example 3: With this RFP, the State of Kansas seeks to procure a modular MMIS, as well as a FA to support some or all of the MMIS. The following are KDHE’s goals for the modular MMIS:

  • Meet the Kansas Medicaid Information Technology Architecture (MITA) 3.0 objectives using the existing Kansas Service-Oriented Architecture (SOA).
  • Meet the Centers for Medicare and Medicaid Services (CMS) Seven Conditions and Standards (7C&S) and promote the use of industry standards for information exchange and interoperability, providing a seamless business services environment for KDHE users.
  • Provide information management tools to assist KDHE in effectively managing the State Medicaid program, business processes, and provide a system designed to accommodate the information needs and business methods of today and tomorrow.
  • Implement eight module components, provided by one or more contractors, to modernize or replace the existing MMIS. For the purposes of this RFP, the term module is used to describe a collection of functionality that can reside in any physical location and is a functional grouping of capabilities that will be implemented, tested, and certified as a single group of system functionality.
  • Kansas is looking for a system that can handle clinical data, encounter and claim processing, and multiple payment methodologies.

(Source: Kansas Request For Proposals EVT0003406,2014)


Example 4: The [State Project Name] project’s leadership has established the following guiding principles, which will serve as the backdrop for this procurement. All decisions will be assessed against these principles on an ongoing basis to ensure that risks are mitigated appropriately, the procurement is successful, and that clients, the provider community and other stakeholders experience minimal impact.


Adaptability: Implement a flexible, rules-based, modular, Configurable solution to enhance decision-making and increase management efficiencies.


Business Intelligence and Data Analytics: Implement business intelligence and data analytic services to enable accurate, real-time data and reporting that will meet changing business and management needs. The solution should be enterprise centric, which would enable other health care and program data typically not found in a Legacy System to support enterprise decision-making.


Service Focused: Structure the procurement to focus on the delivery of services to provide an enhanced customer service experience for providers and clients.


Performance-Based Contract: Implement an incentive-based contract management structure that enables the Department to manage to performance-based service levels for the Contractor, without substantial increased cost to mitigate Offeror risk.


Information Sharing: Implement a solution that provides an easy to access and comprehensive “one-stop-shop” for providers.


Realistic Project Schedule: Structure the scheduled project activities to ensure a quality procurement and a successful implementation of the contracted services and supporting technology.


In addition to the guiding principles identified by Department leadership, the following objectives have been defined:


Maximize Enhanced Federal Funding: Maximize qualification for enhanced Federal Financial Participation (FFP) for MMIS development, implementation, and operations.


Ensure Federal Standards Compliance: Comply with the Centers for Medicare & Medicaid Services (CMS) requirements.


Obtain Federal Certification: Implement project management controls for the development and implementation for all systems to ensure CMS certification. Contractors will receive financial incentives for supporting timely CMS certification in order for the Department to fully qualify for enhanced federal funding.


Integrate with Statewide IT Systems: Ensure that the MMIS is designed for integration with the State’s Medicaid eligibility system (CBMS), Health Information Exchange, and Health Insurance Exchange as envisioned through the Affordable Care Act, and subsequent federal policies and regulations.

(Source: Colorado Department of Health Care Policy and Finance, Core MMIS and Supporting Services Request for Proposals)

Technology Standards

The following are examples in recent MMIS procurements for language demonstrating and/or requiring adherence to CMS Standards.

Example 1: MITA Condition; Modularity Condition:


Pg. 59 Section 5.1.4.2 Conceptual Modular Development Model

The Contractor(s) are encouraged to submit proposals offering a best in class solution and approach under direct accountability to the State for all phases. All proposed solutions will be comprised of proven, advanced technologies coupled with exceptional professional services to support the State’s key objectives and transformation goals. All Contractors are encouraged to submit proposals demonstrating:

  • An evolution to the MITA framework (technology architecture (TA), information architecture (IA), and business architecture (BA)
  • Fulfillment of all the proposed solution(s) requirements outline in this RFP (in part, or whole).
  • Compliance with all applicable State and Federal laws, rules, regulations, guidelines, policies and procedures
  • The ability to adapt to change and respond to changes in the health care industry
  • The ability to learn and adapt to new challenges and paradigms and provide utilities or services that integrate with health care on an enterprise wide level
  • A verifiable record of accomplishment of successful, similar implementations of proposed solutions within a defined timeframe.

Pg. 132

5.2.6.1
2

Will provide diagrams and narratives in the EMP (see 5.2.2.7) for engineering the project components within the data center computing environments (applicable options only). Illustrate the different types of computing environments (as defined in this RFP). Include the following:

  1. Technical Architecture (TA)
  2. Information Architecture (IA)
  3. Network/Communications Architecture
  4. Exchange data services (enterprise shared services)
  5. Interfaces
  6. Performance management system monitoring operations.


Pg. 138

5.2.7.1
10

Will participate in modernization data projects testing events as follows: test defect identification, root cause analysis, and resolution activities related to information architecture (includes legacy data interfacing components), and computing environments. The preceding testing events are in addition to delivered modernization project systems, subsystems, components, and services preproduction activities.


Pg. 145

5.2.7.1
75

Will provide the information architecture specifications (IAS) that includes the physical architecture for the Medicaid enterprise's information strategy and data definitions that comply with and support the requirements of the business architecture (BA) and technical architecture (TA) specifications using the State modernized and Contractors leveraged assets.

5.2.7.1
76

Will provide in the Contractor(s) proposal ISP and specifications intended for the State's Phase II – Modernization MMIS and Phase III - Operations. Include narratives and diagrams of the logical and physical data models, data dictionaries, and preconfigured business rules for computing environment initialization. The information architecture may include files, databases, repositories, operational data stores, transaction data stores, reporting repositories, parameter files, reference files, and reference information and other sources as provided by the Contractor.


(Source: Kansas Request For Proposals EVT0003406,2014)


Additional Documents/Resources Available


Scope of Work

Example 1: The Contractor shall have sole responsibility and accountability for all Replacement MMIS requirements and services mandated by the contract. The Contractor shall assemble a solution that meets the requirements of the RFP comprised of the MMIS modules and components described below, and must supply professional services.

The Replacement MMIS shall be an integration of existing and proven solutions with very limited custom development, must conform to MITA principles, the CMS Seven Conditions and

Standards, and achieve CMS certification. The RFP seeks a solution comprising best-of-breed Commercial-Off-The- Shelf (COTS) products, based on a modular approach, seamlessly integrated as part of a Service- Oriented Architecture (SOA) and supported by professional services. The following sections describe the functions comprising the Replacement MMIS.

(Source: New Jersey MMIS RFP 2014)


Cost Model and Budgeting Specifications

Example 1: The State of Kansas sought to procure a modular MMIS, as well as a Fiscal Agent (FA) and/or a system integrator to support some or all of the MMIS. In providing its cost models, the State provided incentive plans, the options for negotiations, and change orders based on innovation that could potentially reduce operating costs.


Incentive Plans

KDHE may elect to pursue an incentive plan. KDHE in conjunction with the PNC, and Contractor(s) personnel may, as time and resources allow, develop an incentive plan during the course of the Phase II - Modernization.


Payment Modifications

The Phase III - Operations pricing schedules require pricing for the five years of operations. Payment for subsequent years shall be negotiated should the State elect to utilize the contract extension year(s). These requests may be made up to one time annually. Payment for subsequent years shall be negotiated should the State elect to utilize the contract extension year(s). This requirement is in adherence with the SMM 2080.11.


Negotiated Changes

The State is very interested in promoting innovation that shall lower processing costs and the cost of operating the MMIS in general. To this end, the State may share, at the State’s discretion, in the cost and benefit of developing innovative solutions if the Contractor(s) can show how operating costs would be lowered because of the investment. These opportunities shall be dealt with on a situation-specific basis. This requirement is in adherence to SMM 2080.11.


(Source: Kansas Request For Proposals EVT0003406,2014)



Project Management and Governance

Example 1: The following model language from the recent Colorado MMIS RFP addresses the State organization and oversight entities:

3.5.2. The project organization is as follows:

3.5.2.1. Executive Sponsor(s): Consists of members of the Department. Executive Sponsor(s) will oversee the Core MMIS and Supporting Services implementation and provide overall direction for the COMMIT project. Executive Sponsor(s) have final decision making authority related to the project.

3.5.2.2. Claims Systems and Operations Division’s Project Management Office (PMO): A unit within the Claims Systems and Operations Division that manages various projects for the Department. It coordinates, manages, and oversees projects as well as sets agency-wide standards, practices, and policies for project execution. The PMO oversees the Department’s projects including the COMMIT project (RFPs and resulting contracts), 5010/NCCI/ICD-10 efforts, as well as regular updates to the State’s existing MMIS and process improvement projects.

3.5.2.3. MMIS Project Manager: Part of the Department’s PMO and will oversee the MMIS Implementation and Operations project and the Contract for the Department, and will work with the Contractor to provide day-to-day coordination of all project tasks. The MMIS Project Manager will be the primary point-of-contact for the Contractor to the Department.

3.5.2.4. Purchasing Services Section: Oversees the solicitations for the Department and is the main point of contact for this procurement.

3.5.2.5. Independent Verification and Validation (IV&V) Contractor: The Department will identify resources to support IV&V services for this Contract.

The Department will act as a liaison between its Contractor(s) and other agencies and stakeholders. The Department will help facilitate communication between the parties to ensure the COMMIT project has a successful transition and implementation. The Department’s COMMIT Project Manager will act as the primary contact point for the Contractor’s account manager and will escalate necessary issues and risks to the appropriate Department stakeholders. The Department’s COMMIT Project Manager will also coordinate the participation of Department and State stakeholders in Contractor sessions and meetings throughout the term of the Contract.

(Source: Colorado Department of Health Care Policy and Financing, Solicitation # HCPFRFPKC13COREMMIS, Core MMIS and Supporting Services Request for Proposals)


Example 2: The following language is from the recent New York MMIS RFP and addresses expectations for the project management and governance:

Develop and execute a Project Management Plan (PMP) within the first 30 calendar days of contract award, approved by the Department that is based upon industry best practices and standards. The PMP shall include:

  • Quality Management
  • Scope Management
  • Requirements Management
  • Issue Management
  • Risk Management
  • Change Management
  • Configuration Management
  • Performance Management
  • Communication Management

Develop and maintain a project work plan in Microsoft Project that includes each phase of the project that is resource loaded and includes both contractor and Department activities. The work plan shall adhere to industry best practices and standards for project management, and be broken down into Work Breakdown Structures (WBS), including key tasks, milestones, resources, deliverables, and task dependencies.

Establish and staff a Program Management Office (PMO) that manages the PMP and reports directly to the Department Project Management group. The PMO shall also integrate with other relevant state contractors and entities.

Use a project management tool accessible by State staff, in addition to the contractor's team, that includes the following capabilities:

  • Issue and Risk Management
  • Scope Management
  • Configuration Management
  • Change Management
  • Action Item Management

This tool must maintain project information for the full lifecycle of the project.

Make all project management documentation available online to Department and contractor staff, including, but not limited to the PMP, work plan, status report, and status meeting agenda and minutes.

Develop, produce, and maintain a Certification plan that defines the contractor’s approach to federal MMIS certification. It must describe the processes and procedures that will be used to manage Certification requirements throughout the Planning and Implementation Phase; manage the certification activities; processes and procedures that will be used to create the certification documents and assist during the CMS visit; and how these activities are integrated with the contractor’s project management system. The plan must define the contractor’s approach and plan for preparing for certification and performing activities including but not limited to:

  • Completing the initial update of the Certification Checklists in Attachment F of this RFP
  • Completing Certification Phase Deliverables
  • Validating MMIS functionality against the Certification Checklists, creating the Certification Checklist Traceability Deliverable, and maintaining the Certification Checklists
  • Developing and assembling documents that will be used to support the certification process and review
  • Performing a Certification Readiness Test
  • Assisting the Department in preparing for and conducting the CMS certification site-visit
  • Responding to CMS inquiries during and after the site-visit

Deliver detailed training during the project initiation task, on the contractor's processes to be used to complete the scope of work. This training must be specific to the quality management, risk management, scope management, project management and SDLC methodologies proposed by the contractor. This training must transfer knowledge, to Department staff, of the contractor’s Project Management Methodologies in order to participate in creating and reviewing required deliverables and orient Department technical staff and Department contractor staff in configuration management, requirements management and overall design and development programs so that they can productively participate in the deliverable production and review process.

Maintain a project facility for this contract within a ten (10) mile radius of the NYS Capitol building. The facility shall provide adequate workspace for contractor project management, departmental liaison, design, development, and implementation leads, provider relations and member relations staff as well as designated state staff.

(Source: New York Request for Proposals. Replacement Medicaid Management Information System (R-MMIS) Fiscal Agent Services Project FAU Number 1002031048, 2010)



Key Personnel

Example 1: The State allowed vendors to propose multiple individuals for different job duties.


5.7.1. The Department does not require DDI activities to be performed within Colorado, or

by staff located in Colorado. However, a local site with facilities within one (1) mile of the Department shall be provided for collaboration, project planning, and other DDI activities as needed will be required for all Contract Stages.


5.7.3. The Contractor’s Key Personnel are expected to be located locally (within one (1) mile of the Department), but will allow Key Personnel working on DDI activities to be located outside of Colorado during the Implementation Contract Stages if the DDI activities are also performed outside of Colorado.


6.1.2. The Department has identified a list of key job duties that are required throughout the various Project Phases over the Contract term. These job duties shall be performed by Key Personnel, but can be shared amongst Key Personnel roles (i.e., does not necessarily require separate people) where practical and allowed. The Account Manager, Systems Manager, and Fiscal Agent Operations Manager job duties cannot be shared by the same Key Personnel.


6.1.4. Other Key Personnel shall be identified in the Offeror’s proposal indicating the Contractor’s commitment to team stability. As commitment and continuity are important factors in success of the Contract, the Department will consider assignment of highly qualified Key Personnel to any additional positions as a commitment to reduce risk under the Contract. The proposed staffing plan should be focused on retaining both quality staff and knowledge.

(Source: Colorado Department of Health Care Policy and Financing, Solicitation # HCPFRFPKC13COREMMIS, Core MMIS and Supporting Services Request for Proposals)



Project Performance Standards

The following structure from a recent New York RFP provides a good template for laying out performance standards and penalties or incentives:


Project Performance Standards – DDI Phase

Example 1:

Performance Management Measures

Identifier

KPI

Performance/Service Level

Assessed Payment/Recoupment

T16.3

Status Reporting

The Contractor, in a manner acceptable to State, must provide a monthly status report within five State work days after the end of the calendar month.

Five hundred dollars ($500) per State work day the Status Report is not received or is unacceptable to the State.

(Source: Arkansas Request For Proposals, AME MMIS Core System and Services, 2013)


Project Performance Standards – Operations

Example 2:

Within fifteen (15) calendar days of the end of each month of operations, the Contractor shall be required to produce and deliver a report card on its actual performance. All Contract and performance standard requirements identified in this RFP shall be part of the report card. There shall be two (2) sections to the report card, see example below. The first section shall address all Contract and performance standards identified in Sections 40.12.5 and 40.12.6 within this RFP and shall not be subject to forfeiture of retainage as defined in Section 40.12.1 within this RFP. The second section shall address any and all performance standard requirements identified in Section 50 within this RFP or offered in the Contractor's proposal that are not identified in Sections 40.12.5 and 40.12.6 within this RFP.


The [State] intends, thirty (30) days prior to each quarter, to identify twenty-five (25) performance standards of the new [Medicaid] Operations, Maintenance, and Modification Phases and shall use these performance standards to review the Contractor’s actual performance.


NOTE: THIS REPORT CARD FOR EXAMPLE PURPOSES ONLY.

Table 1 – [MMIS] Report Card

MONTHLY REPORT CARD

REPORT CARD PERFORMANCE REQUIREMENT Performance This Month

SECTION 1

The Contractor shall ensure there will be no delays or interruptions in the operation of the [MMIS] and related services caused by any failure, act, or omission of the Contractor. MEETS


SECTION 2

Performance Standard 1:

Files: System shall be available for inquiry and update according to the terms of the contract. The Contractor shall produce a report that shows the number of hours and minutes each day the system is available. MEETS

Performance Standard 2:

A. Imaging: Select ten (10) claims weekly. Compare the date on the source document to the TCN date. Images shall be created within twenty-four (24) hours of receipt. MEETS

Performance Standard 3:

B. Sample ten (10) images a month. Record the time required to retrieve a record systematically.

MEETS

Performance Standard 4:

C. Electronic Claims Submission: System shall be available for receipt and adjudication of claims twenty-four (24) hours per day, seven (7) days per week, except during Commonwealth-approved scheduled downtime. MEETS


PERFORMANCE STANDARD 5: MEETS

40.12.6.7 Timeliness of Claims Processing—Performance Standards

The Contractor shall meet the following requirements:

  1. Adjudicate ninety-five percent (95%) of all clean claims for payment or denial within thirty (30) calendar days of receipt.
  2. Adjudicate ninety-nine percent (99%) of all clean claims for payment or denial within ninety (90) calendar days of receipt.
  3. Adjudicate all non-clean claims within thirty (30) calendar days of the date of correction of the condition that caused the claim to be unclean.
  4. Adjudicate all claims within twelve (12) months of receipt, except for those exempted from this requirement by Federal timely claims processing regulations.


40.12.6.8 Timeliness of Claims Processing—Reduction in Compensation

The [State] may reduce compensation up to ten thousand dollars ($10,000.00) for each failure to meet any of the requirements set forth in Section 40.12.6.7 during the first month.

The [State] may reduce compensation up to twenty thousand dollars ($20,000.00) assessed for each failure to meet any of the requirements set forth in Section 40.12.6.7 within this RFP in consecutive, subsequent months.

(Source: Kentucky Medicaid Enterprise Management System and Fiscal Agent Replacement Request for Proposals, Feb. 2013)


Example 3:


Service Level Agreement

Definition

Damages

Technical Architecture

Production Environment Hours of System Availability

Ensure that all contractor, state, provider, member, and other stakeholder elements of the production environment are operational and available without interruption 24 hours a day, seven days a week, except for scheduled State approved downtime.

$1,000 per minute penalty for disruption in production environment.




Contract Standards

The following model language is from an RFP for a COTS solution for a Health Insurance Marketplace and was crafted in consultation with CMS/CCIIO. This language can be applied to MMIS procurements.


Example 1:

Intellectual Property


(a) [State] Ownership Rights.

Notwithstanding anything to the contrary contained herein, [State] shall have all ownership rights in software or modifications thereof and associated documentation designed, developed or installed with Federal Financial Participation. This clause is only intended to ensure that [State] has all of the ownership rights that are required to be maintained by the State or local government under 45 C.F.R. Section 95.617(a) (subject to the limitations set forth in Section 45 CFR Section 95.617(c)) and 45 C.F.R. Section 92.34.

[State] shall own all right, title and interest in and to (i) [State]'s Confidential Information, (ii) [State]'s Intellectual Property, (iii) Work Products (not including Contractor Technology for purposes of this Section) and the Configurations, (iv) the System "look and feel" (to the extent such "look and feel" is original to the System) and product specifications of [State], (v) all [State] documents and/or policies included in the System, and (vi) all Data input and/or stored by Users on the System.


Notwithstanding Section 1(a)(ii), [State] shall not own and Contractor reserves all right, title and interest in and to: (1) Pre-existing Software, (2) Contractor Technology, (3) Contractor Intellectual Property,(4) modifications and enhancements of Pre-existing Software and other Contractor Technology, or (5) standard configurations included with, and other uses of, commercially available software to the extent that the license for such software does not allow Contractor to provide [State] such rights.


(b) Transfer of Ownership.

Contractor shall take all actions necessary and shall transfer ownership of all Work Product (not including Contractor Technology for purposes of this Section) and the Configurations (not including Contractor Technology for purposes of this Section) upon its delivery. Contractor further agrees, upon [State]'s request, to take all actions necessary to transfer to [State] any ownership rights necessary to ensure [State] has all ownership rights reserved to [State] by Section 1(a).


Contractor shall provide to [State] copies of specified, available Work Product and the Configurations upon [State]'s request. As between the Parties, all Work Product (not including Contractor Technology for purposes of this Section) and the Configurations (not including Contractor Technology for purposes of this Section) shall be deemed works made for hire of [State] for all purposes of copyright law, and copyright shall belong solely to [State]. In the event that any Work Product (not including Contractor Technology for purposes of this Section) or the Configurations (not including Contractor Technology for purposes of this Section) is adjudged to be not a work made for hire, Contractor agrees to assign, and hereby assigns, all copyright in such Work Product to [State]. Contractor shall, at the expense of [State], assist [State] or its nominees to obtain copyrights, trademarks, or patents for the Work Product (not including Contractor Technology for purposes of this Section) and the Configurations in the United States and any other countries. Contractor agrees to execute all papers and to give all facts known to it necessary to secure United States or foreign country copyrights and patents, and to transfer or cause to transfer to [State] all the right, title and interest in and to the Work Product (not including Contractor Technology for purposes of this Section) and the Configurations. Contractor also agrees to waive and not assert any moral rights it may have in any of the Work Product (not including Contractor Technology for purposes of this Section) and the Configurations.


(c) Data.

Notwithstanding anything to the contrary contained herein, all plan data, provider network data, and other Data provided by insurance carriers to [State] or Contractor for purposes of the Project shall remain the property of such insurance carriers. From time to time as necessary [State] will obtain the consent of insurance carriers to permit the use by [State], Contractor and Users of such insurance carrier's data on the System.


All Data, including all consumer data and/or carrier data stored by Contractor hereunder shall be stored exclusively at locations within the continental United States.


Contractor shall provide [State] with a copy of all Data which is on the Equipment used for the System within five (5) Business Days of a request from [State]. Contractor shall provide such Data to [State] up to four (4) times per Year at no additional cost to [State]. Contractor shall provide such Data to [State] on magnetic [or electronic] media in a format acceptable to [State].


(iv) Except to the extent that Contractor shall be required to retain such information under Section [reference Record Retention clause] hereof, at the end of the Term of this Contract Contractor shall delete or destroy all Data that is owned by [State] pursuant to this Section 1(c), provided, however, Contractor shall not be required to delete such Data from its electronic data archives that are retained solely for emergency back-up and recovery purposes so long as such Data is promptly and permanently deleted in the event such archives are ever accessed for recovery purposes.


(d) Licenses to [State].

Contractor hereby grants to [State] nonexclusive licenses to: (1) use and access remotely the System and the Hosting Services, (2) use and access the Software, and (3) use, demonstrate and reproduce the Software (provided in Object Code) solely for [State]'s internal purposes. With respect to Third Party Software, Contractor will either (i) cause [State] to be granted nonexclusive license rights from third parties, including Subcontractors, or (ii) procure such rights for itself such that [State] may enjoy use of any third party software embedded or integrated into the Software and the System. Contractor agrees to procure, at its sole cost and expense, all such rights for [State]. To the extent needed, the licenses granted in this Section 1(4) are granted as of the date of delivery to or availability for [State] and continue through the entire Term of this Agreement, provided, however [State] shall have the right to retain a copy of the Software (in Object Code) solely for archival purposes.


(e) Licenses to Contractor.

[State] hereby grants to Contractor, subject to any restrictions applicable to any third-party materials embodied in the Work Product, a perpetual, nontransferable, non-exclusive worldwide, royalty-free, paid-up right and license to use, copy, modify and prepare derivative works of the Work Product for purposes of Contractor's business, including the right to sublicense. Contractor shall indemnify, defend, and hold harmless [State] from and against any and all losses, liability, claims, actions, damages, penalties, costs, fees or expenses, including, without limitation, legal fees and expenses, arising from or caused by any act or omission of Contractor, its officers, employees, agents, or Subcontractors related to Contractor's exercise of the rights and licenses described in this Section. Contractor shall require that any recipient of any [State] Confidential Information which is contained in such Work Products be kept confidential comparably to Contractor's obligations in this Agreement to keep confidential such Confidential Information.

[STATE] GRANTS NO WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON­ INFRINGEMENT FOR THE WORK PRODUCT.

Contractor shall apprise, through its license agreements or otherwise, any other party to which Contractor provides such Work Product that [State] provides no warranty, express or implied, for such Work Product. In no event will Contractor be precluded from independently developing for itself, or for others, anything, whether in tangible or non-tangible form, which is competitive with, or similar to, the Deliverables. In addition, Contractor will be free to use its general knowledge, skills and experience, and any ideas, concepts, know-how, and techniques that are acquired or used in the course of providing the Services.

(Source: Mississippi Health Insurance Marketplace Contract)

==

State Procurement Process

Within this section, State-specific procurement regulations will govern the majority of the structure and language used. The following provides an outline from the Utah MMIS Replacement RFP for the sections covering the material as well as a few sample language excerpts:


Example 1:

4 PROCUREMENT BACKGROUND

4.1 ISSUING OFFICE AND RFP REFERENCE NUMBER

4.2 OVERVIEW OF PROCUREMENT PROCESS

The major steps of the procurement process are as follows:

  • The proposal must be submitted electronically via BidSync and via hardcopy, see section 6 for the specific requirements.
  • Proposals must be received by Division of Purchasing by the submission deadline. Proposals not meeting the submission deadline will be rejected.
  • Proposals meeting the submission deadline will be screened to ensure that they meet the mandatory submission requirements.
  • Technical proposals will be evaluated by a committee selected by the Division of Medicaid and Health Financing.
  • Final Cost proposal evaluation is restricted to those Vendors who meet the minimum technical requirements.
  • Final scores will be compiled and a recommendation will be made to the Director of the Division of Medicaid and Health Financing.


4.3 CONTRACTING OFFICER

With the exception of oral presentations and interviews scheduled by the State, the Division of Purchasing is the sole point of contact from the date of release of this RFP until the selection of the successful Vendor. All questions and requests for clarification must be submitted via the BidSync System.


4.4 MANDATORY LETTER OF INTENT TO BID

4.5 WAIVER TO CONTINUE CONTACT WITH DMHF

Any Vendor (including sub-contractors) having contact with DMHF individuals for normal operation activity, under any other contract currently in place with DMHF or the Office of Inspector General of Medicaid Services (OIGMS) must request a waiver to continue such contact with DMHF or OIGMS. The letter requesting this waiver must be received by the Division of Purchasing at the location described in Section 6 by the letter deadline defined in section 1.2.


4.6 QUESTIONS REGARDING THE RFP

All questions must be submitted through BidSync. Answers will be given via the BidSync site.


4.7 WEB SITE

4.8 ORAL PRESENTATIONS

4.9 PURPOSE OF ORAL PRESENTATIONS

The sole purpose of such oral presentations provides Vendors an opportunity to clarify their technical proposal, provide an overview of the merits of their technical proposal, answer questions or concerns raised by the State in the course of reviewing the technical proposal, and assist the State in verifying the capabilities of the Vendors. It also provides an opportunity for the State to question the Vendor’s team about the experience, expertise, and qualifications that they bring to the Project. Information gathered during oral presentations will be used in evaluating and scoring technical proposals.


4.10 QUESTIONS AND OTHER REQUIREMENTS FOR ORAL PRESENTATIONS

The Vendor is not permitted to enhance or modify their original technical proposal during oral presentations. Vendors shall not attend, in whole or in part, presentations by their competitors, nor shall Vendors interfere with the oral presentations of their competitors. Each potential Vendor shall ensure that key individuals whom it bids for the Utah SYSTEM project will attend all or part of its oral presentation. Specific questions will be asked and requests for clarification of the Vendor’s technical proposal will be made as the State deems appropriate. Vendors may be asked clarifying and follow-up questions by evaluators. Vendors may be asked questions regarding individual qualifications and perceptions about how they will contribute to the Utah project and interact with the State project team. Responses made during the oral presentations will be considered a part of the Vendor’s proposal.


During the oral presentations, Vendors shall not discuss or reveal any information contained in their cost proposal and shall not discuss the merits or qualifications of their competition. For the oral presentations, the State may, at its discretion, establish such procedures and rules of conduct as it may deem appropriate, and the State may enforce such procedures and rules of conduct.


4.11 KEY PERSONNEL INTERVIEWS

The State reserves the right to conduct interviews of the bidders key personnel proposed to work on the Utah SYSTEM project.


5 RULES OF PROCUREMENT

5.1 ACCEPTANCE OF TERMS AND CONDITIONS

5.2 AMENDMENTS TO THE RFP

5.3 COST OF PREPARING THE PROPOSAL

5.4 DISPOSITION OF PROPOSALS

5.5 PROTECTED INFORMATION

Provides Utah specific guidelines regarding what information can be marked proprietary and the steps vendors must take to protect any portion of their proposal.


5.6 NO CONTINGENT FEES

5.7 INDEPENDENT PRICE DETERMINATION

5.8 REFERENCE CHECKS

5.9 SUBMISSION OF INFORMATION CONCERNING ANOTHER VENDOR

5.10 GIFTS AND KICKBACKS

6 PROPOSAL SUBMISSION REQUIREMENTS

In addition to the electronic submission via BidSync, one (1) original, two (2) identical hard copies, seven (7) e-readers and fourteen (14) universal serial bus (USB) flash drive copies of the Technical Proposal along with all attachments searchable as a whole, in Microsoft Word or portable document format (PDF) must be submitted. In addition to the electronic BidSync submission, one (1) original, two (2) identical hard copies, and three (3) flash drive copies of the Cost Proposal along with all attachments searchable as a whole, in Microsoft Word or PDF must be submitted.


The Technical Proposal will include technical, professional, and corporate information as well as a transmittal letter. For a full discussion on required contents and format of the Technical Proposal, see Section 11 TECHNICAL PROPOSAL INSTRUCTIONS below.


The Cost Proposal will contain the cost and pricing data for the contract and the appropriate pricing schedules. Section 12 COST PROPOSAL INSTRUCTIONS provides a full discussion of the submission requirements for the Cost Proposal and Pricing Schedules.

6.1 PROPOSAL AMENDMENTS AND RULES FOR WITHDRAWAL

6.2 STATE’S RIGHT TO REJECT


Example 2: The following representative language is also from the Utah RFP and outlines the evaluation process:


13 PROPOSAL EVALUATION

DMHF will conduct an evaluation of Vendors’ proposals based on the procedures described in this section. The evaluation will consist of the following steps:

· Step I – Initial evaluation of Cost Proposals;

· Step II – Evaluation of mandatory requirements for technical proposals;

· Step III – Evaluation of technical proposals;

· Step IV – Evaluation of cost proposals;

· Step V – Oral presentations and Site Visits(Optional);

· Step VI – Ranking of proposals; and

· Step VII – Selection and award.

The contract resulting from the procurement award becomes effective upon signature by the responsible State officials and approval by CMS.


DMHF will appoint an Evaluation Committee (Committee) to support the evaluation process. The Committee will include State staff representing such areas as information technology (IT), MMIS operations, finance, and Medicaid policy. The Committee will be responsible for reviewing and scoring the proposals received in response to this RFP and staging oral presentations for those Vendors qualifying as finalists. The Committee will then rank Vendors based on each Vendor’s combined technical and cost scores and present their findings to the DMHF Director for a recommendation to the Purchasing Officer for contract award.


Authorized State and Federal officials who are not committee members may observe the evaluation and selection processes. The State reserves the right to alter the composition

of the Committee.


13.1 STEP I – INITIAL EVALUATION OF COST PROPOSALS


13.2 STEP II – EVALUATION OF MANDATORY REQUIREMENTS

A detailed checklist of what would be evaluated in this step was provided in the RFP.


13.3 STEP III – EVALUATION OF TECHNICAL PROPOSALS

The evaluation of technical proposals will involve individual review and assignment of points based on each Vendor’s response for the following rating categories. The rating categories disperse a maximum of 700 points for each technical proposal. The criterion for evaluating each category is included in this Section. The categories and possible points for each category are shown below:


Rating Category

Points

Corporate Background and Experience

180

Project Organization and Staffing

140

Technical Approach

200

Project Management and Quality Assurance

100

Work Plan and Schedule

80

Total

700

Any technical proposal that contains pricing information will be disqualified. The following paragraphs describe the evaluation criteria supporting each evaluation category.


Detailed criteria were provided in the RFP but removed here for space in each of the following categories.


13.3.1 Corporate Background and Experience (180 Points)

The State will evaluate the experience, performance, corporate resources, and corporate qualifications of the Vendor and any sub-contractor(s). The evaluation criteria for Corporate Background and Experience are:


13.3.2 Project Organization and Staffing (140 Points)

The project organization and staffing response should include detailed criteria to evaluate the Vendor's overall organization for the project, the qualifications of key personnel, the experience with the proposed technology and the past performance of the company and the proposed staff. The Committee will also evaluate the adequacy of the staffing plan to support the project timetable. The evaluation criteria for the Vendor's Project Organization and Staffing are:


13.3.3 Technical Approach (200 Points)

The Vendor's technical approach will be evaluated including the Vendor’s response to Sections 10, 11.5, 14.4.2, 14.4.3, its System Development Life Cycle (SDLC) methodology, its approach to incremental implementation, its requirements traceability approach, integration of technology with the State’s IT environment, and its knowledge transfer approach. The evaluation criteria for the Vendor’s technical approach include:


13.3.4 Project Management and Quality Assurance (QA) (100 Points)

This part of the evaluation assesses the Vendor's approach to project management and QA in relation to the Vendor's past experience in meeting project contractual obligations. The evaluation criteria for the Vendor’s Project Management and QA approach include:


13.3.5 Work Plan and Schedule (80 Points)

The Vendor’s draft work plan should include a detailed work plan with resources, schedules and contingencies. It should also contain a narrative of the project effort, deliverables, and controls instituted to control the proposed work schedule. The evaluation criteria for the Work Plan and Schedule include:


13.3.6 Assigning Point Values to Technical Proposals


An explanation of each of the steps identified above was also included but not included here for space.

(Source: Utah MMIS Replacement RFP)