The awful performance of healthcare.gov has been a staple of the news as well as satire. This cartoon in the New Yorker this week sums of the frustration of users – http://www.newyorker.com/humor/issuecartoons/2013/11/04/cartoons_20131028#slide=4
I normally don’t like to comment on hot news stories, but this one offers just too much of a teachable moment, especially for public officials who are not technologists, yet who will suffer public criticism when things go bad.
It’s worth noting that this is not the only case of Federal IT system problems. Before healthcare.gov, the great cost and the long delays of the FBI case management system were in the news. And, not to be outdone, New York City had a major scandal with its timekeeping system, both for the huge cost (close to $750 million) and the fact that there was a significant amount of that money diverted into the personal pockets of the project staff.
Indeed, costly and disastrous software projects are not just found in the public sector. It only seems so because the public sector problems are more visible thanks to taxpayer funding, whereas the private sector can keep its mistakes better hidden.
In part, this review of bad projects reminds me of an old line in IT project management. “Of the three goals of any the project – being within budget, on time, and of good quality – you’re usually only going to get two, but not all three.” But, for the Affordable Care Act, is none of the three some kind of trifecta?
Part of the problem is that these projects cost way too much money. That’s often because of rules intended to ensure everything is above board and serves the taxpayers’ interest, but which have the reverse effect. And so ultimately, the purpose of the procurement rules is, as a well-intentioned government attorney once told me, to follow the rules – not necessarily to get maximum value for the taxpayers. The big companies that dominate Federal technology projects have learned to master these rules and not necessarily do the best job. Their reputations are also victims of this focus on process, rather than outcomes.
Another reason for the bloating of these projects is simple ego. Some top executives have the belief that big important projects should have big budgets.
Unfortunately, this attitude fails to distinguish the cost of writing the software from deploying it. The cost of software development does not increase much if the number of users is 100 or 100,000.
Obviously, the cost of deploying that software will increase in a linear fashion the more people who use it because the deployment may require more servers, more complex database arrangements, etc.
But spending hundreds of millions just to develop the software is usually unjustified.
So what can be done by executives who have to deliver new systems to the public, but feel they are enveloped in a fog of technical jargon so don’t question things until it’s too late.
Consider these alternative ways of handling software projects, none of which is really new, but seem to be not well known to non-technologists in both government and elsewhere:
- Adopt the agile approach – this means having frequent deliverables and thus taking advantage of learning by users and developers. It stands in contrast to the traditional practice of big requirements documents and all at once delivery of mammoth amounts of code.
- Frequent testing, which is also a part of the agile approach. It’s so important that some people build the test before the software. After all, proof of the pudding is in the eating and it’s useful to know you’re off course earlier rather than later.
- Parameterize. This is something you don’t hear too much about, but it’s something I’ll mention here because some of the healthcare.gov vendors blamed their problems on changes in Federal decision making about whether users need to register first. I would always tell my development staff this simple rule – if the debate about whether some requirement should be X or Y will take longer to resolve than it takes to program it both ways, then program it both ways by creating a parameter that will switch the system one way or the other. Don’t let these debates hold up progress of software development. (By the way, if the debate is that hot, there is good reason to expect the decision to change in the future, which will cost more money in future programming. So parameterize and let the decision makers argue and change their minds as much as they want.)
- Gradual scaling – don’t roll out a big new piece of software to the whole world at once. (Do we really need to say this?) If the scale of deployment is expected to be a possible problem, why not minimize the problem by taking it in several steps and, again, learning what needs to be improved. Even experienced Broadway veterans try out the show on the road first.
- Simplify deployments by using a scalable infrastructure. There’s much discussion about “the cloud”, which is really just a good marketing term for the vast scale of computing resources available over the Internet. Use it instead of trying to reinvent this vast scale, which is impossible for any organization, no matter big. Many Internet businesses you’ve dealt with use these resources to handle peak demand or initial rollouts.
I could go on, but these guidelines are normally enough to keep your next big systems project out of the headlines.
© 2013 Norman Jacknis
[http://njacknis.tumblr.com/post/65612237318/isnt-there-a-better-way-to-build-government-software]