Why state IT projects fail: a much-overlooked factor

Oliver Olsen, the once and (perhaps) future State Representative from southern Vermont, recently wrote an essay entitled “Why IT projects fail.” It was, more specifically, about why state-contracted IT projects fail.

Olsen began with the question, why can’t we bulid a software system when we manage to build large-scale complicated stuff like highways, bridges, and suchlike. His explanation: while the basics of civil engineering have been in place for quite a while, the world of high technology is young and ever-changing. And it’s harder to deal with the intangible world of IT than with the steel-and-concrete world of construction.

Good enough, as far as it goes, and I recommend reading the piece.

But I’d add one big factor that no one else seems to have noticed.

One of the problems throughout the history of the Affordable Care Act and Vermont Health Connect is a lack of competition for IT contracts. CGI was the big dog, by a long shot. Vermont chose CGI in large part because it had won so many other ACA contracts that it seemed the clear choice. Turned out, of course, that CGI wasn’t really up to the job. And when Vermont went to find a replacement, the only real choice was Optum, upon which our hopes are now pinned.

So the question: Computers and software are huge growth industries, and the US excels at both. Why can’t we get more, and smarter, companies to bid for health care exchange contracts?

I’d turn that question around: why are so many high-tech companies staying away?

Could it be because public-sector projects are complicated, fraught with peril, and more likely to yield failure than success?

Just looking at how the market moves, I have to conclude that it’s a lot more profitable to build newfangled gadgets, computer games, and smartphone apps. And the cost of failure is a whole lot lower: you put out a device or a game or an app. If it fails, you move on to the next one and write off the development costs. If you’re trying to build a health care exchange, you’d better damn well get it right. You can’t just walk away in the middle, and you can’t unilaterally postpone the launch.

Also, whereas a game or an app is pretty much a stand-alone item (as long as it plays nice with the operating system), public-sector IT projects are complicated systems that have to interface with other complicated systems.

There are lots of things IT experts can do that are higher-return and lower-risk than public-sector IT projects. Which is why most of them stay away from the business, and the public sector is left with a relative handful of bidders.

And somehow I doubt that those bidders represent the best and the brightest of the IT world.

1 thought on “Why state IT projects fail: a much-overlooked factor

  1. Oliver Olsen

    A few thoughts:

    1. IT project failures are just as prevalent in the private sector as they are in the public sector; they just aren’t as visible to the general public. Few private enterprises will advertise internal failings (IT or otherwise), but it is hard to sweep even the smallest failures under the rug in the public sector.

    2. You are correct that systems that involve integration with other systems are often the most complex, but again, this is not unique to the public sector. In general, there are new opportunities for failure introduced with each customization and/or integration added to an IT project.

    3. There are plenty of high tech companies that bid on large public (and private) sector IT projects and make a lot of money delivering those projects. The investment required to submit a bid for a large IT system is substantial – typically hundreds of hours – so few IT companies are going to put in a bid unless they have a high degree of confidence that their bid has a real chance of success.

    4. The comparison with technology companies that build consumer software and devices is interesting, but I would disagree with the conclusion that it tries to support. Unlike a product development company, IT contractors are generally paid by the hour or for a deliverable, even if the end result does not live up to expectations. Just like a lawyer, doctor, or other professional, win or lose, at the end of the engagement, the IT contractor moves onto the next client. On the other hand, a company that turns out product (hardware or software) for mass consumption (e.g. Apple) does not survive unless it keeps turning out great products and has sufficient capital to absorb the occasional flop. In summary, in a project environment, the client is almost always left with the risk (and reward) of project’s success/failure.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s