Appendix F: Procurement options analysis examples

In deciding which procurement strategy would best fit the needs of a product, developing an analysis of alternatives for the different options that are available helps provide data to make decisions.

Example #1: Centers for Medicare & Medicaid Services (CMS) — Medicare Payment Modernization contracting strategy

Background

As modernization efforts transitions from proof of concepts on the Fiscal Intermediary Standard System (FISS) to a production roadmap, serious thought must be put into the contracting strategy to support this effort for the next 5–10 years. Setting up the correct contracting strategy has the largest impact on the probability of success on this effort. The FISS system is the initial target for proof of concepts to be transitioned into production, this effort shouldn’t be limited to just that system. This is a unique opportunity to synthesize diverse Medicare payment systems. Including the following:

• Common Working File (CWF)
• Multi-Carrier System (MCS)
• VIPS Medicare Shared System (VMS)
• Centers for Medicare & Medicaid Services Innovation (CMMI) models

To achieve the goal of a successful payment modernization effort, contracting strategy must enable the following factors:

• Ability to award new tasks quickly
• Quality of technical talent available via contract vehicle
• Contractor digital service experience and approach (this is different than “agile development”)
• Familiarity with CMS systems, specifically complex business logic associated with Medicare FFS payment processing
• Ability to define development and infrastructure requirements at the blanket purchase agreement (BPA) level so details aren’t missed in task orders

There exists a variety of contracting options, each with pros and cons. It’s the effort of this document to determine which contracting option best suits needs for this modernization effort. Ultimately, the decision on choosing the right contracting strategy needs to answer the simple question of: Will this vehicle/strategy position the Medicare Payment Modernization effort to have the greatest probability of success?

Pros and cons of different procurement options

Strategic Partners Acquisition Readiness Contract (SPARC)

The Office of Information Technology (OIT) at CMS has an existing indefinite delivery/indefinite quantity (IDIQ) vehicle called SPARC that’s the agency’s answer to agile, waterfall, and hybrid development methodologies. This vehicle has a $25B ceiling that houses over 140 different vendors. Its goal is to be the one-stop shop for agency development. There are certainly advantages to leveraging work already completed as well as drawbacks to leveraging a generic development contacting vehicle.

SPARC with on-ramp

This option has the ability to continue leveraging SPARC while allowing for new vendors to be added to the IDIQ. This list includes all of the Pros and Cons listed previous with SPARC with the following consideration.

Governmentwide Acquisition Contract (GWAC) — General Services Administration (GSA) Alliant 2, National Institutes of Health (NIH) CIO-SP3, etc.

Agency-wide BPA

GSA Schedule task order competitions

The GSA Schedule is available for individual task orders as they are necessary.

Project-specific BPA off of GSA Schedule

Digital services contracting approach

While there are a variety of potential contracting options available, to-date, the most successful approach to complex system development at CMS using an innovative, digital service approach, was done on the Quality Payment Program.

Some high-level stats on the QPP BPA to-date:

• There have been 16 task orders awarded under Agile Delivery to Execute Legislative Endeavors for Quality Related Initiatives (ADELE)
• All vendors are small businesses
• Every ADELE BPA holder has won an award at this point
• All ADELE task orders have been competitively awarded
• Zero protests
• The average procurement action lead time is 67 days
• The average period of performance for an ADELE task order is 2.2 years
• Responses were typically limited to 20–25 pages with 2-week turnarounds
• Low-dollar value allows for Contracting Officer’s Representatives (COR) II rather than COR III

Retrospective: SPARC vs. ADELE

As previously listed, the goals for our contracting strategy are:

• Ability to award new tasks quickly
• Quality of technical talent available via contract vehicle
• Contractor digital service experience and approach (this is different than “agile development”)
• Familiarity with CMS systems, specifically complex business logic associated with Medicare FFS payment processing
• Ability to define development and infrastructure requirements at the BPA level so details are not missed in task orders

CMS has experience over the past year issuing contracts through both SPARC and ADELE and there are some great data points that can be gathered to compare the two vehicles against the goals that we’re aiming for.

Ability to award new tasks quickly

Working in an agile fashion means not having all of the business requirements up front. Most of the time this process is impossible and a vast majority of the time the initial business requirement gathering for a complex system is incorrect. As new requirements come to light throughout the modernization process, the ability to issue contracts rapidly is necessary.

Quality of technical talent available via contract vehicle

Competition is vital in making sure the government is getting the best possible vendor for the job. More vendors doesn’t always mean better competition. Contracts see the best competition when vendors specialize in the work that issued. Overall competition increases as vendors learn through previous proposals. Finding the sweet spot of the vendor pool size that allows for competition and allows vendors to continuously challenge each other to rise the skill level is important.

Contractor digital service experience and approach (this is different than “agile development”)

User-centered design, DevOps, and product management are required to deliver modern digital services. These skillsets, along with an agile methodology, are necessary in delivering working software in small increments allowing for quickly changing development and design as new requirements are discovered.

Familiarity with CMS systems, specifically complex business logic associated with Medicare FFS payment processing

Having a background with CMS programs allows vendors to hit the ground running when contracts are awarded. The amount of time that’s required to either onboard or transition work is diminished when vendors already know systems that they’ll be working on. Having these familiarities allows for the period of performance to decrease and thus protecting CMS from getting locked into a vendor that underperforms. In addition to familiarity, having a smaller vendor pool means that contractors and their employees already have accounts, access, and the ability to quickly begin work after contract award.

In some cases it takes over two months for new contractors to get access to CMS systems. This would make any attempt at iterative development dead on arrival.

Ability to define development and infrastructure requirements at the BPA level so details are not missed in task orders

Having certain requirements that can be found in all contracts that are intended to go out under the vehicle can benefit from having these requirements baked into the vehicle directly vs. requiring justification on each contract. This protects CMS from potentially missing common contracting needs with each contract issued. This also cuts down on the size of the proposal that needs to be reviewed with each task order.