X
Business

Medical Emergency

CIO magazine has an article written by Allan Holmes, describing Maine’s attempt to develop and deploy a web-based system for processing Medicaid claims and payments. The project was started back in 2001, to help the state to modernize its systems and also ensure compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA).
Written by Michael Krigsman, Contributor

CIO magazine has an article written by Allan Holmes, describing Maine’s attempt to develop and deploy a web-based system for processing Medicaid claims and payments. The project was started back in 2001, to help the state to modernize its systems and also ensure compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

The project was a mess, but there are a whole bunch of fantastic project failure lessons we can learn from this story. Here are just a few of the key lessons:

1. Buy cheap, get cheap.  My friend George Cha, president of AG Capital Management, taught me that phrase. And boy, does it apply here. From the article:

In April 2001, the state of Maine issued an RFP for the new system. But by the end of the year, the state had received only two proposals: one from Keane (for $30 million) and another from CNSI (for $15 million).

Typically, agencies like to see several bids within a close range. That way, procurement officials are confident that the requirements are doable and the bids realistic. In this case, the low bidder, CNSI, had no experience in building Medicaid claims processing systems. In contrast, Keane had some experience in developing Medicaid systems, and the company had worked on the Maine system for Medicaid eligibility.

2. Make up your own rules. This is one of my all-time personal favorites. After all, why wait for those pesky subject-matter experts, when you can just take a guess yourself? From the article: 

…the 65-person team composed of DHS IT staffers and CNSI representatives assigned to the project had difficulty securing time with the dozen Medicaid experts in the Bureau of Medical Services to get detailed information about how to code for Medicaid rules. As a result, the contractors had to make their own decisions on how to meet Medicaid requirements. And then they had to reprogram the system after consulting with a Medicaid expert, further slowing development.

3. Hide the truth. No matter how bad the situation seems, don’t tell management. Again, from the article:

Looking back, Thompson says the DHS team was seriously understaffed. But Thompson says he was afraid to ask for more resources. "That is a significant problem in government," Thompson says. "If I say I need 60 to 70 percent more staff because we need to work this project for two years, the response would be, ‘What, are you crazy?’ So, we just couldn’t make the turnaround times."

4. Don’t test. After all, testing is evil. Again, from the article:

In an attempt to catch up, they began to cut corners. For example, testing the system from end to end was dismissed as an option.

5. Don’t train users. Let’s face it, training is expensive and also a hassle. So why bother? To their credit, the project folks in Maine followed this rule:

Beyond a few fliers announcing the new system and new provider ID codes, HHS offered little or no guidance to providers on the use of the system. And there was no training for the staff who would have to answer providers’ questions.

6. Never, ever run in parallel. That’s right — not ever. Again, from the article:

HHS dismissed the idea of running a parallel system as too costly and complicated.

Take a look at the article — it’s quite detailed and makes an interesting read.

Editorial standards