Regardless of your political or social views regarding the U.S. Federal health insurance mandate, known as the Affordable Care Act (or perhaps less affectionately as “ObamaCare “), there can be no question that the first three weeks of the Federal health exchange website’s online existence have been an unmitigated disaster. I don’t know an IT’er who wouldn’t cringe at what has happened, for two reasons: first, it’s guaranteed that something like this has happened to them in their careers (if perhaps – hopefully – on a lesser scale), and secondly, because they can guess what went wrong and how some things could have been avoided.

The details of the website’s problems have been very hard to uncover, probably because of all the political posturing surrounding the law itself. As the President said in his Monday 10/21 Rose Garden talk, the website isn’t the law – it after all is just a website. However, to confirm or correct my suspicions about the failures of the technology implementation, I had to do a fair amount of Googling before I could find any details at all. Finally, I did find an excellent piece in New Republic entitled “The Truth About The Obamacare Rollout ” by Jonathan Cohn. And that article in turn brought to mind several reminders about systems implementations in general, and how retailers might want to take note.

Without knowing the exact details of any of the particulars (Which systems? Which contractors? What integrations? What standards? Which service providers? Etc. etc.), there are lessons to be learned, that apply to retailers as they consider re-tooling their application portfolios to meet new market demands.

The Natural Laws of Computing are in Force

Back in the early days of RSR’s “Selling Tech Value To Retailers ” seminars, I used to show a slide entitled, “The Twelve Natural Laws Of Computing ” (author unknown). Here they are (with yeah-but corollaries supplied by me):

1. Technology breakthroughs require a surrounding infrastructure
2. Enterprise solutions must be managed on an enterprise basis
3. Things break
4. Change causes the most downtime
5. Industry standards inhibit innovation (Yeah-but corollary #1: “Innovation isn’t always what you want “)
6. Market share wins, not technical eloquence
7. Competitive advantage is hard
8. The scope of every computer project grows
9. New computer technologies unveil additional layers of applications which suddenly become feasible and cost effective (Yeah-but corollary #2: “yeah, but they also cause developers to lose focus. “)
10. Size is the greatest determinant of implementation difficulty
11. Serendipity doe not apply to computer systems. If a system was not designed from its inception to be portable, scalable, intuitive, maintainable, or integrated – it is not. (Yeah-but corollary #3: “… and never will be no matter how much money you throw at it. “)
12. If data resides in two places, it will be inconsistent.

I don’t see anything in the Obamacare website story to contradict these time-proven rules. For example, in his piece Cohn says, “Obamacare’s architects assumed that most states would opt to run their own marketplaces, with federal officials running only a few. The assumption proved wrong: Pretty much any state with a Republican governor or Republican legislative control said no, adding to the administrative burden on HHS (the Federal Department of Health and Human Services). ” Of course the first warning is the word, “assumed “. Oops! That is one of the most feared and cringe-inducing words in all of IT, as in, “I assumed that you knew that we wanted…. “). But beyond that, it points to Natural Laws #10 and #8.

Unplanned Volume Can Kill Ya’

The 10^th Natural Law is about the complexities that come with volume. No retailer knows this better than Walmart. A company insider once told me that the company’s systems logically were very straightforward. All the complexities came from having to deal with vast amounts of data. It was for that very reason that for years Walmart wouldn’t consider using commercially available solutions – they believed (justifiably) that there wasn’t a system available that could handle what they could throw at it.

The Obamacare website was apparently designed with the assumption that state exchanges would be the norm, not the exception. Oops again! Whether they planned it this way or not, GOP governors threw a big wrench into the works – only 18 states currently have exchanges, while 23 states have explicitly ruled them out, essentially defaulting a huge (and apparently unplanned) volume of people onto the Federal exchange site. Maybe the Feds should talk to the folks at Walmart… since Arkansas is planning an exchange partnership with the Federal government, there’s an opportunity for share some knowledge!

Things Break (Especially When Quality Takes a Backseat)

Then the author points out that, “It’s… possible that cabinet agencies are not set up to run these kinds of operations well, at least not on such a large scale and under such a strict timeline. ” In other words, there was a brick-wall deadline that wasn’t to be missed, no matter what. Having lived (if that’s the right word) through such implementations in my own past, here’s what I know: first, the project team will start jettisoning requirements left and right as the strict deadline approaches; secondly, shortcuts will be taken; third, quality takes a backseat; and fourth (perhaps the killer) measures to make the system operationally ready will be ignored (or in other words, no matter what the Operations staff says, this thing is going live, so “shut up and deal with it. “). Those realities bring Natural Laws #1, #2, #3, and #4 into effect.

The real concern ought to be Natural Law #11, specifically, “If a system was not designed from its inception to be portable, scalable, intuitive, maintainable, or integrated – it is not. ” With the exception of “intuitive ” (perhaps), all of those other design issues are related to operational readiness. Every CIO worth his or her salt knows that job #1 is service level. But developers don’t usually care much about that – in fact, those reliability requirements often will get postponed to the inevitable “2^nd release “.

I’d be willing to bet that the developers of the ACA site did exactly what developers everywhere do when they are facing an unmovable deadline – they punted on operational readiness. But that brings up the risk of “future shock ” too. Natural Law #11 mentions “integrated “, and it’s a fair bet that along with operational readiness requirements the design hasn’t much considered future integration requirements either. And so there’s a risk that the future ACA site will need significant re-work when new integration points are required. That’s when my “yeah-but ” corollary to #11 gets to be a big deal ( “…and never will be no matter how much money you throw at it. “). Let’s hope I’m wrong.

Retailers know how this feels, because they have experienced the same thing with their POS systems. Companies are struggling now with how to integrate their legacy POS (which was assumed to be an “island ” technology rather than part of an enterprise-wide selling platform) to new e-Commerce and m-Commerce capabilities. If you believe in the truthiness of Law #11, then you’re facing the need to replace that old POS system – and maybe the legacy e-Commerce system too, in favor of an “integrated selling environment “.

Ch-cha-ch-ch-Changes

In his article, Jonathan Cohn says, “The architects of Obamacare weren’t simply trying to build websites, after all. They were trying to build a whole new health care system. ” This might be the most important learning from the ACA website mess: fundamental change is really, really hard. Using the high failure rate of IT projects as the reference point, a 2012 McKinsey report said that the keys to better implementations are:

• Managing stakeholders rather than budgets and schedules
• Securing critical internal and external talent
• Building effective and aligned teams
• Excelling at core project-management practices, such as short delivery cycles and rigorous quality checks

With all the political crossfire going on about the new law, building true consensus among the stakeholders wasn’t going to happen But “consensus ” is an overused word. It comes from Latin, meaning “harmony “, but its practical meaning is “majority opinion “. Sometimes leaders can’t wait for that – they know they their organizations (country or company) must change in order to remain competitive (Natural Law #7!). So, people need to know where their leaders are taking the organization, and what will be expected of them, and then they need to be managed through the change cycle. The best example I can think of, of a company that did this right, is Nordstrom. The company changed out its entire merchandise management system in the early-mid 2000’s, but they spent the money and time required to get their people ready for that change. In other words, they didn’t assume (that word again!) that people would go along because they had no choice.

It’s important for people to know where they’re going and what they should expect- in other words, they need some leadership. As Cohn points out, “People trying to get insurance have been remarkably patient, which tells you something important about how dysfunctional and frustrating the old insurance market was. ” But as the saying goes, “the devil you know is better than the devil you don’t. ” So if the objective isn’t clear, it’s unlikely to be achieved. Corporations and governments are not alike in this way: the corporate leaders can and should set a direction but don’t have to put it to a vote. But managing people through the change is the biggest part of the change – not the technology that enables it.

So as retailers ponder the massive technology-enabled changes that they must undertake, it finally gets to the real issue – people. To avoid their own little ACA-like meltdown, retailers need to spend as much money and time working their people (customers and employees) through the change process as they do on the technology. The Federal government will undoubtedly do what needs to be done to fix the ACA website (as many retailers have done to muddle through a botched technology implementation), but there IS a better way.