Republican senators and representatives are not the only government employees working against the success of HealthCare.gov and the Affordable Care Act. An IT CEO who has worked on government projects in the past has eloquently described another faction in the fight: people who don’t want to learn new technology and who defend their work turf at all costs.
Dave Kellogg is the CEO of Host Analytics, which provides cloud-based enterprise performance management. Previously, he was general manager of service cloud at Salesforce and CEO at unstructured big data provider MarkLogic. Medicare chose MarkLogic’s database software to run part of HealthCare.gov. MarkLogic’s software manages data differently from systems by companies like IBM, Microsoft and Oracle – products more commonly used in government projects.
He worked at MarkLogic until 2010 and did not have a role in any HealthCare.gov work, as best he can remember. However, the implied criticism of his former company prompted a great post about the many challenges of working with the government on technology projects.
It had never occurred to me, for example, that in a $630M project — where MarkLogic might get maybe $5 to $10M — that someone would try to blame failure of what appears to be one of the worst-managed projects in recent history on a component that’s getting say 1% of the fees.
It makes no sense. But now, for the second time, the New York Times has written an article about the HealthCare.gov fiasco where MarkLogic is not only one of very few vendors even mentioned but somehow implicated in the failures because it is different.
He points out that this kind of failure happens all the time on projects of this scale. This is the best and most concise critique I’ve read of the HealthCare.gov mess: Someone who didn’t understand how hard it was to build ordered up a website of very high complexity with totally unrealistic time frames.
He also points out another problem I’ve seen as I’ve worked with IT people to build websites: Most people like to stick with what they know. This tendency is not unique to IT pros, but the implications of that problem have a much bigger impact when the skill in question is technology.
Here is Kellogg’s analysis:
A Deep-dive Into Specialty Pharma
A specialty drug is a class of prescription medications used to treat complex, chronic or rare medical conditions. Although this classification was originally intended to define the treatment of rare, also termed “orphan” diseases, affecting fewer than 200,000 people in the US, more recently, specialty drugs have emerged as the cornerstone of treatment for chronic and complex diseases such as cancer, autoimmune conditions, diabetes, hepatitis C, and HIV/AIDS.
The trick with selling disruptive technology to the government is that you encounter two types of people.
- Those who look objectively at requirements and try to figure out which technology can best do the job. Happily, our government contains many of these types of people.
- Those who look at their own skill sets and view any disruptive technology as a threat.
I met many Oracle-DBA-lifers during my time working with the government. And I’m OK with their personal decision to stop learning, not refresh their skills, not stay current on technology, and to want to ride a deep expertise in the Oracle DMBS into a comfortable retirement. I get it. It’s not a choice I’d make, but I can understand.
What I cannot understand, however, is when someone takes a personal decision and tries to use it as a reason to not use a new technology. Think: I don’t know MarkLogic, it is new, ergo it is a threat to my personal career plan, and ergo I am opposed to using MarkLogic, prima facie, because it’s not aligned with my personal interests. That’s not OK.
The trouble is that these folks exist and they won’t let go. The result: when a $630M poorly managed project gets in trouble, they instantly raise and re-raise decisions made about technology with the argument that “it’s non-standard.”
Oracle was non-standard in 1983. Thirty years later it’s too standard (i.e., part of an oligopoly) and not adapted to the new technical challenges at hand. All because some bright group of people wanted to try something new, to meet a new challenge, that cost probably a fraction of what Oracle would have charged, the naysayers and Oracle lifers will challenge it endlessly saying it’s “different.”
Yes, it is different. And that, far as I can tell, was the point. And if you think that looking at 1% of the costs is the right way to diagnose a struggling $630M project, I’d beg to differ. Follow the money.
