Thursday, October 24, 2013

The Obamacare Tech Mess? It's A Familiar Government Story





In this Oct. 11 computer frame grab, a HealthCare.gov website message is displayed.



Uncredited/AP


In this Oct. 11 computer frame grab, a HealthCare.gov website message is displayed.


Uncredited/AP


By this point, it's all but a universally acknowledged truth that the launch of the HealthCare.gov website has been a failure.


That's bad news for President Obama and his health care law. But it's not exceptional when it comes to big government software programs and platforms.


Earlier this year, California ended a contract to modernize its payroll system, an effort that had eaten up 10 years and $250 million and gotten essentially nowhere. Colorado has had a number of high-profile embarrassments when upgrades to its revenue systems caused residents tax refund and car title problems, while Florida legislators last year scuttled a $70 million attempt to unify the state's email systems.


In fact, governments at every level — but particularly states and the feds — have suffered expensive, embarrassing flops when it came time to roll out new information technology (IT) projects.


"The bigger the system, the harder it is, because there are more variables," says Steve Kolodney, a former chief information officer for the state of Washington.


It isn't just size.


Private sector companies generate plenty of software flops, too. But the way governments typically manage computer projects — with diffuse authority, penny pinching and a deadly combination of delays and rigid deadlines — they're especially prone to producing disappointment.


No One Really In Charge


It doesn't seem like there should be any great trick to designing new systems. We've all become accustomed to using our computers or phones to easily order new barbecue sets along with a dozen out-of-print books, or to stream old sitcoms all weekend.


So why is it such a trick for government to get people signed up for health insurance, or make appointments at the Department of Motor Vehicles?


There are a bunch of reasons. The first problem is that top-ranking government officials often expect these things to be easy. They come up with some application they want started up and then expect the IT guys and their vendors to make it happen.


It's like having no knowledge of what goes on under the hood, and then pulling into the dealership and asking them to design an entirely new car.


"They proudly announce that they don't understand the technology — 'my 14-year-old knows more than I do,' which is a moronic statement," says Gopal Kapur, founder of the Center for Project Management in California.


Legislators and agency heads may not know anything about lines of code, but that doesn't keep them from second-guessing the tech folks. They tend to view IT as a drain on resources and wonder why they have to keep buying new versions of software to keep up.


When it comes to government projects, Kapur says, people know they have to spend money in a given year, because funding may dry up the following year. Planning for upgrades over, say, a three-year period just doesn't happen the way it should.


"Companies don't fall apart because a new CEO comes," he says. "If you go to a state, nobody does anything for a year before the governor's going to change, and then the year after nobody does anything because they don't know what the governor wants."


Keeping Up With The Times


Big government projects can take years to build, which means the world of technology will have changed dramatically since a given project began.


There's just been a new iPad released, for instance, but think about how important tablets have become in just the past few years. You wouldn't want to design a user interface today that didn't take into account mobile computing.


But governments typically don't budget for the need to overhaul entire project designs along the way. And, because of strict procurement rules, the IT staff may not be able to buy new products it needs, sometimes for more than a year at a stretch.


Meanwhile, policymakers keep asking for new features. There may be changes in law that have to be incorporated within a website. The budget deal that reopened the government this month, for instance, included stricter income verification requirements for people signing up for coverage under the health care law.


That's not why HealthCare.gov isn't working, but things like that happen all the time. It's as if a developer had to start construction of an office tower using an incomplete set of blueprints and then was told at the last minute to add another elevator shaft and a couple of bathrooms per floor.


Some people in the IT world like to argue it's never the technology that's at fault, it's the management.


"Good governance, not superior technical chops or ready access to alpha geeks, is how you build complex systems that deliver reliable and resilient value for money," Michael Schrage, a research fellow at the MIT Center for Digital Business, wrote in a Harvard Business Review blog post Tuesday.


Getting Ready In Time


There's no end to software snafus in the private sector. A filing with the Securities and Exchange Commission just last week outlined how a software bug led trading firm Knight Capital to lose $172,000 a second for 45 minutes.


Still, governments demand perfection in a way that private companies generally do not. Obama compared the health care website's problems to Apple, and that company's problems with its maps app show how even the best-run brands can run into trouble.


A better comparison might have been with Google, however, which releases beta versions of programs it knows will have bugs. That company relies on crowdsourcing to find and help fix any issues.


"That's not the model in government," says Doug Robinson, executive director of the National Association of State Chief Information Officers, or NASCIO.


"In government, you want to release something that's absolutely rock-solid perfect the day you release it to the market," Robinson says. "That might not be possible."


Knowing a big release date is coming — say, Oct. 1 for the exchanges at HealthCare.gov to go live — doesn't lead to new levels of quality control. Instead, problems are patched and may be overlooked by agency heads or other managers who just want to get the thing up and running.


A new website might have all the latest and zippiest features, but if it's having to talk to antiquated systems — as is often the case with back-end government operations, which offer differ wildly by agency — it still may not work.


"States certainly have had their fair share of projects that have failed or at least underperformed after tens or hundreds of millions have been spent," Robinson says.


Check The Vital Signs


To combat some of these problems, states such as California and Indiana are now making public what they call the "vital signs" of every major project, allowing politicians and the public to keep track of how every aspect of development is proceeding along the way.


It's like when the police release details about a case, but not necessarily every scrap such as the name of the victim, says Kapur, in hopes the public can offer information that might help the case.


The government itself, however, is ultimately responsible. That's why it was important that the president himself came out on Monday and took his lumps about HealthCare.gov's failures, Kapur says.


Often, it's the IT people who are forced to face the cameras. They have to explain why things aren't working, but typically lack the power to make changes that can turn a project around.


"They can find the problems and report the problems, but they don't have the political or administrative authority to change what is causing the problems," Kapur says.


Source: http://www.npr.org/blogs/alltechconsidered/2013/10/24/240247394/the-obamacare-tech-mess-its-a-familiar-government-story?ft=1&f=1019
Related Topics: Marquez vs Bradley   Maria de Villota   Julius Thomas   Amanda Berry  

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.