With Biczak's assistance, the Bureau of Information Services set up a triage process for the help desk. Medicaid business-process questions would be sent to the Medicaid specialists; software and hardware questions would be sent to IT program specialists. The triage process was implemented in January. By the end of the month, Thompson claimed the new system could process 85 percent of claims as either pay or deny. "I can now see the light at the end of the tunnel," he says.

For the provider community, however, that light is still the headlamps of an oncoming train. Gordon Smith, head of the Maine Medical Association, says the new claims system is still far from what was promised: an advanced system that would clear claims faster, track costs better and give providers more accurate information on claims status. Smith disputes Thompson's claim, saying the new system still rejects 20 percent of the total claims, most of which meet accepted standards for payment. "Why are we comparing this system to a legacy system that wasn't good enough in the first place?" he asks. "Why spend $US25 million on a new system that isn't any better?"

For doctors like Flanigan, the entire ordeal - the postponed payments, the lack of communication with providers, the system's continued fallibility - will not easily be forgotten. Or forgiven. And it will certainly be on Flanigan's mind when he and others like him go to the polls to vote for governor in November.

"They are supposed to be protecting the most-at-risk people in the state," Flanigan says. "It goes beyond shock and dismay how utterly disrespectful the state has been to providers and patients."

SIDEBAR: 10 Steps to a Successful Project

1.Scope out a detailed plan. Describe what the system must do for users and how you will measure the performance of the system and its output.

2.Watch out for bad RFP bids. A low number of bids or bids that are not within an acceptable range suggest that the requirements have not been properly communicated or are unrealistic.

3.Plan ahead. Line up subject matter experts who know the business processes for the new system and can provide guidance to developers and programmers during buildout. Assign a business expert full-time, or nearly full-time, to the implementation. Create a steering committee that includes subject matter experts and developers, and meet frequently.

4.Find the bottleneck. You can develop a system only as fast as it takes to build the most complicated component. Many times the delay is not from writing code, but rather something else, such as finding time with a subject matter expert. So, resist hiring more programmers to speed up the development process until you analyze what is slowing down the project and focus resources there.

5.Do not cut corners on testing. The last thing you want to do is ignore critical pilot tests and end-to-end tests. Ultimately, such corner-cutting will result in longer delays later. If you need more time, ask for it, and defend why you need it.

6.Develop a backup system. If replacing a legacy system, make sure the users can fall back to the old system if the new system fails and needs to be reworked.

7.Prepare other contingency plans. As part of your backup plan, be prepared to communicate with system users so that they can use the backup system and know what is expected of them.

8.Train, train and train. Provide frequent training for internal staff on new business processes and system requirements, including what must be done in case of a system failure. Train call centre staff on how to manage users' questions. Train users on how to use the system and what they should do in case of failure.

9.Honesty is your best policy. In case of failure, provide honest answers to users and staff. Do not make promises that you do not know you can keep.

10.Triage fixes. In fixing a flawed system, prioritize fixing those requirements that have the biggest impact on users and that provide basic, needed functionality. Come back to the bells and whistles later.