Deloitte's Medicaid Management Information System (MMIS) implementations have generated more than $400M in federal audit findings and remediation costs across multiple states. The federal government's Inspector General reports, state audit findings, and CMS corrective action plans document a consistent pattern of failure across California (MEDI-Cal), Florida, Indiana, and other states. These failures were not random — they followed architectural and delivery patterns that are identifiable in advance.
Understanding the failure pattern is not about criticizing Deloitte specifically — McKinsey, Accenture, and CGI have produced comparable failures in government IT. Understanding the pattern is about recognizing when the same conditions are present in a current engagement and having the technical and contractual tools to prevent the same outcome.
Failure Pattern 1: State-Specific Custom Development Without Abstraction
MMIS implementations are inherently complex: they must satisfy federal CMS requirements while accommodating state-specific Medicaid program rules, eligibility categories, benefit structures, and reporting requirements. The failure mode: building state-specific customization directly into the core system rather than through a parameterization layer. When CMS requirements change, every state-specific implementation must be updated separately — and in large programs with 50+ developers across multiple contractors, that becomes impossible to manage.
The architectural requirement that prevents this: a rules engine or configuration layer that separates state policy from system logic. The system implements the MMIS functional requirements; the configuration layer defines state-specific parameters. Changes to state policy are configuration changes, not code changes.
Failure Pattern 2: No Compliance Validation in the Delivery Pipeline
CMS MMIS certification requirements (CMS MITA 3.0, the seven MMIS functions, the Medicaid Enterprise Certification Toolkit) define specific functional, technical, and compliance requirements. In the failed implementations, compliance validation was treated as a pre-certification exercise — done once, near the end of the project, by a compliance team that was separate from the development team. When compliance failures were found, they were too embedded in the architecture to fix without significant rework.
CMS's MECL (Medicaid Enterprise Certification Lifecycle) requires that state systems demonstrate compliance with the MITA 3.0 business process standards and the CMS seven conditions and standards. These are not documentation requirements — they require working functionality. A system that documents compliance with MITA 3.0 but doesn't implement the corresponding system functions will fail CMS certification. Deloitte's California MEDI-Cal implementation was repeatedly delayed by CMS certification failures traceable to this gap.
Failure Pattern 3: Governance That Isolated Technical Decisions from Regulatory Requirements
Large MMIS programs typically involve multiple stakeholders: the state Medicaid agency, CMS, the prime contractor, multiple subcontractors, the state IT agency, and the governor's budget office. The governance structures that failed consistently had one characteristic: the people making technical architectural decisions were not the same people responsible for regulatory compliance, and the two groups didn't have regular structured interaction. Technical decisions that created compliance debt were made without awareness of their compliance implications, because compliance was someone else's job.
Failure Pattern 4: Timeline Pressure That Traded Compliance for Velocity
MMIS projects are politically exposed: delays make headlines, cost overruns draw legislative attention, and state Medicaid agencies have operational dependencies on the system going live. The resulting timeline pressure creates a consistent failure mode: compliance-critical work (testing against CMS requirements, security assessment, data validation) gets compressed or deferred when schedule pressure mounts. The deferred work creates the compliance debt that the auditors find later.
How to Avoid the Pattern
- Require parameterization architecture in the contract — state-specific policy should be configuration, not code
- Build CMS certification requirements into the definition of done for every sprint, not into a pre-certification phase
- Establish joint governance between technical delivery and regulatory compliance from project inception — not as separate workstreams
- Include compliance validation in the CI/CD pipeline — automated tests against CMS MECL functional requirements
- Contract for compliance-first delivery with defined compliance gates — go/no-go criteria that include compliance validation, not just functional delivery
- Build in federal CMS engagement from the project start — surprise late-stage CMS feedback is avoidable with early engagement
The Vendor Rescue Pattern: How to Recover a Failed Implementation in 12 Weeks
FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant
How Accenture's Staff Augmentation Model Creates Compliance Debt (And How to Audit It)
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.