I recently read that the State of Minnesota spent $41 million, not including legal fees, on software that was never completed. The program was supposed to simplify and automate much of the processing for MinnesotaCare eligibility determinations. This system would speed up processing and reduce fraud.
In reading the article, I felt it was important for me to learn more about how this happened to see what business analysis or quality assurance techniques could help prevent a project nightmare on this scale.
Eating an Elephant
Many of you have probably heard the saying, "How do you eat an elephant? One bite at a time." The point of this saying, of course, is that in order to accomplish a huge task, you need to break it down into small pieces. As you accomplish each smaller piece, you get closer to your goal.
Based on the Minnesota Auditor’s report on this project from 2007, I think that the root cause of this project failure was that the project sponsor wanted to eat the elephant in one bite. The auditor’s report specifically says that some factors contributing to project delays were "initial underestimates of project complexity" and "changes in project scope." The changes in project scope included adding additional categories of eligibility to the initial plan and changes to state law.
In addition, according to this 2009 story from Minnesota Public Radio, the business architect said that delays were partially due to "literally thousands of changes," and the Assistant Attorney General said that the delays were due to "literally thousands of defects that required correction." When a project is broken into smaller pieces, it should not get to a point where there are thousands of changes or thousands of defects.
Having a grand vision for a software project isn’t a bad thing. However, it’s important to break down that grand vision into smaller deliverables. This has several benefits:
- Usable functionality is available much earlier;
- Usable functionality is available even if the budget is unexpectedly cut; and
- Proof exists that the development team can deliver before the entire budget is spent.
How could this project be broken down into smaller pieces? Based on what I know about the project, a hypothetical breakdown could be:
First, build and deploy a data collection system that simply collects information in the same format as the existing paper forms. It would contain basic data entry validation, but it would not validate any business rules other than the most basic ones.
- Benefit: All new applicants are entered into the system. Basic data entry errors are kept out of the system. Shortcomings of the deployed system are identified for coding improvements in future phases.
Next, chose a small subset of the most straight-forward and common of the "115 different eligibility categories" to automate. Build and deploy this processing into the production system.
- Benefit: A large portion of the manual processing is eliminated. Shortcomings of the deployed system are identified for coding improvements in future phases. The system can be modified as laws change.
Now, continue to add small numbers of eligibility categories to the system for automated processing as they are defined.
- Benefit: The benefits of the system are not delayed due to the difficulty of defining and coding the most complicated eligibility rules.
In the end, it may be that some of the most complex eligibility categories continue to be handled through a manual process. The Pareto principle tells us that it’s likely that we could automate 80% of the applications with 20% of the overall development effort. That would bring tremendous benefit to the applicants and the State even if the system was never fully automated.
Of course, a key component of Embedded Quality, "No code is ‘Complete’ unit it is tested and works correctly," should be used to further break down the development into even smaller pieces.
The State’s Plan
The MPR article states that the State of Minnesota wants to attempt this project again. Unfortunately, a quote from a person involved in the project makes me worry that the next attempt won’t be any more successful. The state Medicaid director said, "the agency is now considering developing a single system to determine who qualifies for all health and welfare programs, including welfare and food stamps."
I’m not sure that adding complexity to the system is the best way to go!
I’d like to hear about your experiences with nightmare projects. Have you been involved with a large project that failed? If so, what do you think should have been done differently?