Politics aside (let me emphasize that), for both IT and business professionals who are empirically grounded, I think it’s fairly evident that something is not only horribly awry at present, but also; cascading issues will yield an exponential number of problems as the current system is exercised in full – if ever, that is.
It’s not a matter of fixing discreet troubles – a couple isolated in this module here, a few in that procedure over there. There is an undetermined, interwoven, set of malfunctioning elements. Having professionally managed many projects directly, and having directed project teams in both Fortune500 and Federal environments, it is easy to see the “back side of the screen” trainwreck of this endeavor, from the evidence readily available on the “front side of the screen.” And, recognize that this system tethers to quite a few others – Healthcare.gov is not only an imbroglio to itself: It has the power to corrupt several other critical sites, both in the private-sector and public (government) realms.
A Couple Erroneous Terms:
Website: First, let’s understand this – ObamaCare is not a “website,” as it is referred to in many quarters. It is a highly complex computer program application (really a set of programs), represented by millions upon millions of lines of code – and that is supposed to be available through a simple portal: The associated website. In total, it is not an efficient coding endeavor, and to boot, the overage of code does not match real-world ‘business’ requirements: that is, the business of registering people and allowing them to shop for affordable healthcare. Characterizing this as a “website” helps to mask the gross inefficiencies and problems we’re all facing…
Glitches: The system is not suffering “glitches.” It has deep, entrenched, and very fundamental technical and program flaws. Bringing in the “best and the brightest” for fixes to so-called “glitches” may actually compound the problem. To use a hackneyed, but very useful, phrase: 9 women cannot make a baby in 1 month. Innumerable “best and brightest” types, with their fingers simultaneously in the pie, may actually make things worse. One has to ask: Where were a measured number of “best and brightest” these past 3 years of effort (toward the Go-Live of this thing)?
Speaking of Go-Live – I never missed that date with any of my myriad projects these past decades. Milestones were reality-based, paired with interim reality-based testing, which in-turn delivered results that yielded efficient fixes during the project’s course, and Go-Lives yielded actual business programs that could be used to good purpose on Day 1. That is, fully functioning programs, software, and applications that allowed 100% support to the business at-hand. Any “glitches” were truly minor in scope – easily fixed, and generally same-day – and we were always able to offer users work-arounds in getting business done in the meantime. Day 1. Period.
Consider something I spoke of in my book, I.T. Wars – IDRU: Inadequacy, Disaster, Runaway, and Unrecoverability. Read that chapter, and you’ll see why I believe this system will be scrapped, and started anew – much as the FBI’s VCF (Virtual Case File) System was. In that circumstance, a post-9/11 effort to transition paper records to an electronic system of terror-tracking and management was necessary so that allied agencies could more effectively share and collaborate through utilization of necessary data: The FBI, NSA, CIA, etc. However, in that case, there was comparatively little political consequence in starting over.
IDRU applies here because:
Inadequate attention was given to the project’s scope, its requirements, its timeline, true expectations for delivery, its true course and progress, and the inadequate awareness for the folly of going live with something that was wholly dysfunctional. (By the way: The first day’s screen splash of “The System is Down” was erroneous. A system had to have been Up to be Down. The actual status was: “The System is Not Yet Ready”).
Disaster: Certainly any system that delivers a 100% failure on a promised (and ballyhooed) Go-Live date is a disaster – in an IT-context certainly. However, even the Act’s supporters are beginning to call this rollout “the greatest IT disaster in history.”
Runaway: We may well be in a zone whereby more and more resources are poured into this thing, with ever diminishing results. As the size of the team increases, errors and challenges in simple communication become ever-larger, more and more reports are required – with associated efforts and oversights. Ever more programmers are stepping on other programmers’ changes, and as related, ever more meetings are required for preclusions, negotiations, and fixes to “fixes.”
Unrecoverability: This specific project (not the Act) may indeed be unrecoverable – it may yet be trashed, and started anew. However, it will not be positioned that way for public consumption. The Affordable Care Act, and the related website/system, will be reported as undergoing major revisions, with the requirement for registration likely seeing a major delay… to sometime in 2014, for example. A great analogy serves here: If you have a pyramid of cheerleaders, and several on the bottom are in the wrong uniform, you must have everyone clamber down and stand around as a measure of cheerleaders don the correct uniform. You cannot “fix” the existing pyramid. You have to disassemble, and start over: Once everyone is in the correct uniform, you can re-mount the pyramid. In the case of the Affordable Care Act, “pulling” and fixing modules, lines of code, tables, tethers (to outside systems), databases, etc., is going to create an ever-widening circle of problems. As problems accrue, overlap, and self-reinforce, their growing aggregate will become like a snowball rolling downhill; accruing mass, accelerating the system toward doom – a condition of true runaway, leading to unrecoverability.
Any person in the business-IT realm worth their salt knows this: In IT, an ounce of prevention is worth 10,000 pounds of cure.
With ObamaCare, political considerations preclude the admission that the system is dysfunctional, and not likely to get better any time soon – and that it must be remounted from a fresh start. Either way, an enormous effort is necessary: I believe it may take a year to get a fully-functional system (regardless of anyone’s opinion as to what a functioning system may be enabling and delivering in terms of real-world, affordable, readily-available, healthcare policies).
The Affordable Care Act and its associated online enablements have a number of rollout issues, and whatever the present citizen/user experience is at the moment, there is very obvious evidence of what is wrong with the system that speaks in a special way to this readership:
This readership is comprised of people who operate on empiricals: Actual measures of things in match to real-world requirements. We are comprised of programmers, system architects, engineers, Agile-adherents, project managers, IT managers/directors, CIOs, CTOs… that list can go on. Readership also includes a sizeable number of non-IT, tech-savvy, personnel who inhabit “business-stakeholder” expertise and standing in the enterprise-business-IT realm. CFOs, CEOs, COOs, business owners, business directors, finance and accounting staff, and all manner of managers and allied staff.
Most of us here in this readership would call the ObamaCare rollout, and its associated web-enablement HealthCare.gov, a disaster. It’s almost a reflection for the death of empiricism.
After all, how many of us here have delivered a business system on the Go-Live date that didn’t work?… that didn’t work at all?