Froma Stateline article "Making IT Work",
An estimated 85 percent of government IT projects fail to come in on-time, on-budget or both. “The IT project road is littered with failure, cost-overrun, mission creep, bad contractors, systems that don’t deliver, failed relationships between the parties,” ticks off Dianne Lancaster, chief purchasing officer in Oregon and president of the National Association of State Purchasing Officers (NASPO).
That is pretty sobering. Dissecting the causes shows that both government and private partners are to blame for some of the failure, and the article does some of that dissecting. Government agencies need to have their ducks in a row up front, and structure parnerships to work. Private IT companies need to take more realistic approaches and be willing to accpet and manage risks better.
The article does a good job of pointing out some of the recurring problems that can be fixed simply by learning from others experience. I'd say we should be looking hard at the 15% that work and see what they did right as well.
The article boils the lessons learned down to:
But based on experience, most agree states can take the following steps to ensure smoother sailing.
- Involve all vested agency officials from planning stages through project completion and testing.
- Ensure that vendors and state managers fully understand project parameters and scope before bidding begins.
- When possible, conduct a two-stage bidding process in which finalists submit a prototype design before the winning vendor is selected.
- Form a strong vendor relationship that balances accountability with flexibility.
- Build a strong state management team to oversee projects through final implementation.
From many years of looking at these partnerships, good and bad, myself, I would add:
1a. Government managers need a full and complete inventory of existing systems, equipment, software, interoperability, etc. Many of these deals crash because the actual state of things is much worse than is believed before the project starts.
3a. Structure the deal based on outcomes in terms of service levels and capabilities, rather than prescribing certain hardware and software or architectures.
4a. Make payments depend on meeting outcome goals, not on time or work completed, but also have a strong and flexible partnership that lets you deal cooperatively with the unexpected.