Successful MMIS Implementations (Part 2 of 3)

This is a continuation from Part 1...

In this part, the barriers to success are discussed...

Managing the Cost, Scope, and Schedule Triangle

MMIS procurements are are generally conducted in a very risk averse environment; however, the projects often desire new technologies and innovative approaches to solve current and anticipated business problems. In addition, business objectives and goals are sometimes overshadowed by deadlines for federal mandates and an expiring current MMIS contract. A fixed price contract is a convenient mechanism for states to shift risks to the vendor; costs are capped, and scope is in theory contained. On the surface it is an attractive situation -- the project management triangle is established where cost, schedule, and scope have been defined. However, if scope or schedule change, there is an obvious impact on the cost. Having a fixed price framework does not allow the cost to change hence compromising scope and schedule.

Loss of Context during the Request for Proposal Development Process

State agencies have to start the MMIS procurement Request for Proposal (RFP) very early in order for it to go through the acquisition process. The term used for procurement documents varies from state-to-state but the documents are collectively referred to as the RFP in this paper. As mentioned at earlier, the high cost, visibility, and political nature of these projects generally means that many stakeholders have to be involved and it naturally takes time to address everyone’s needs. State agencies typically undergo a long and arduous process to collect the RFP requirements from their stakeholders. These requirements are usually gathered through either formal or informal requirem ents elicitation sessions. Meaning, anticipated users of the MMIS and other stakeholders involved in MMIS business processes are solicited to capture the requirements for the new system. The exact process and the degree of formality vary from state-to-state; many states contract with consulting organizations that have expertise with Medicaid to help develop the requirements for the RFP (and perhaps develop the entire RFP). A significant negative side effect of this approach is that much of the valuable information related to the requirements is usually lost in the process. The context surrounding each requirement is very important to the vendor responsible for DD&I. The context includes information such as who asked for the requirement, what was the intent behind the requirement, relative priority, discussions, diagrams, and other artifacts. The value of requirements elicitation is often not in the exact requirement statement resulting from the process but rather in the discussion around the requirement. Good analysts probe and ask questions and tackle a specific need from a variety of angles as they form the actual requirements statement. However, the information conveyed during that discussion is difficult to capture in an RFP context. The English language is also not precise enough to convey the information since there are many ways to interpret statements. Also, requirements are not prioritized; a particular requirement may be high-effort and low return.

The time period between when state stakeholders first meet to identify the requirements to the point when the DD&I vendor conducts a requirements verification or validation session can range from one to two years. By that time, it is very difficult to remember the intent behind the requirement. Stakeholders sometimes question why a requirement was even in the RFP during a DD&I requirements verification/validation session. This is often the case because requirements gathering exercise take place at too high a level in the organization. Precious DD&I time has to be used to uncover history and to attempt to bring back the context of the discussion around a requirement. That time period is difficult to predict and quantify while developing a proposal response to the RFP. The consultant or group that conducted the RFP requirements elicitation for the state is often not available once the contract is awarded to the vendor.

Requirements Maturity Challenges Scope and Estimation Processes

Large, complex systems are difficult to define and specify. The procurement documents (i.e., Request for Proposals) define requirements for these systems; however, the requirements are often broad and high level and, as mentioned above, much of the context around each requirement is lost in the process. The requirements for the MMIS are represented as one or two sentence statements. They are often organized around the functional areas of an MMIS such as Claims, Provider, and Member. Over the past several years the RFP requirements have become more detailed and thorough. The sheer number of requirements in RFPs for the entire MMIS has grown from around 100 to over 2,000 over the past four years. However, the requirements are still very broad and high level. Consider these examples from recent RFPs:

• “Ability to apply Expedited Prior Authorization criteria to claim data”
• “Ability to query on provider attributes, as defined by the user”
• “The system must support rebate negotiations”
• “[The system must provide] Enhanced premium assistance functionality”

In addition, many of the requirements include phrases such as “including, but not limited to” and “etc.” that make it extremely difficult for the vendors to bind the scope. RFP requirements are also often not written to follow industry best practices to be clear, concise, and testable. Vendors are required to estimate a two to three year DD&I period based on requirements written to the specificity above. It is a difficult task. So the FFP price will often reflect the risk of the unknown. To bind the scope, vendors will often document assumptions as a part of the proposal in response to these requirements. These assumptions may prove to be inaccurate during DD&I resulting in some form of a conflict between vendor and the state agency. The question and answer period during the procurement process is not adequate to explore and probe vaguely written requirements because there is limited opportunity to have face-to-face contact with the end users and, as discussed below, the right resources and thought process behind these requirements is lost. The end result is that the scope side of the project management triangle is not as solid or firm as is assumed when undertaking the FFP contract for an MMIS project. At best, the schedule side of the triangle is murky given the vagueness of the requirements. Scope and schedule uncertainty eventually impacts the cost.

So what can we all do to address these challenges? Stay tuned...