Healthcare.gov: There’s NO app for that.

 In the beginning of an automated system project, business owners envision all of the automated features that they’ve seen before, and even some that they’ve just imagined. Some, if not all of the White House pols and speech writers “let” the president compare the Exchange to buying things from Amazon and the price comparison experience to Travelocity.  Was this an intentional over-simplification for sound-bites and “talking points”, or was it a gross underestimation of the complexity of the undertaking?

After pouring over left and right media accounts, internal emails, memos, a red team briefing and several progress reports, I’ve concluded that the administration at the high levels were close to clueless as to the technical complexity and the time required to develop as system with complex and difficult technical requirements.  Among these 'difficult technical requirements' are:

•     Identity Proofing: associating an internet-based transaction with a real person and validating that association with little-to-no doubt.  This is required for both privacy and subsidy/tax purposes.  There’s no app for that.

•   Agency Interfaces: to validate identity and to determine eligibility and amount of tax subsidy the Exchange has to compare information submitted to it by the prospective customer to The Social Security Administration, Internal Revenue Service, The Department of Veterans Affairs, The Department of Homeland Security and others as a part of determining eligibility (citizenship, eligibility for other insurance programs. Annual income, and other eligibility criteria. This means that the Exchange needed to interface with existing, OLDER agency systems.  Or it meant that these agencies needed to build a new system to provide such information to the Exchange’s data format and content specifications. There’s no app for that.

•        State and Insurance Company Interfaces: All 36 states, and some 170 insurance companies also need to interface with the Exchange.  The states that built their own web-marketplaces need to use the part of the Exchange that performs the Identity Proofing and Agency Interface capabilities.  The insurance companies need to upload information about their offerings and pricing of some 4,500 plans, There’s no app for that. 

•   Volume:  The idea that tens of millions of customers might show up at one time even scares Amazon on “cyber monday”…. and they’ve been in the business since they went online in 1995.  There’s no capacity or precedent and definitely no app for that or even for calculating it.

So it appears that the political folks and the policy folks that were ‘in charge’ of this complex undertaking did not obtain or trust technical and management staff, expertise or advice from proven sources.  Instead it seems that they relied on gross technical oversimplification, hubris, mismanagement or misinformation.  At this point it almost doesn’t matter which, and it was probably a mix of all of those.  On Dec 1, we’ll see if their attempts to recover will work.  Unfortunately there is no RECOVER app either.

Is healthcare.gov suffering from new, modern I.T. problems or is it the same-old, same-old?

 After reading the first three posts, someone asked me (thanks dear) why the themes listed focus on negative aspects, rather than on positive ideas about how things should be done.  For me, the answer is that I have neither interest in regurgitating what is already documented in texts, nor interest in creating a new one.  There are libraries of excellent texts; many professional disciplines and certifications; an ample number of proven life-cycle methodologies; industry-wide standards and practices; and educated, seasoned professionals ‘out there’. Perhaps, there are too many sources and methods from which to choose.

 What sparked me to write about systems projects gone awry was watching the healthcare.gov project crash. As more information about its problems became public, I expected, more accurately, HOPED to see some new category of problem, some unforeseeable root cause, some hidden threat that emerged late in the project.  I reasoned confidently: that the system at the center of the 100-years-in-the-making legacy achievement for the Administration would get the ‘best and brightest’, and would get high level detailed, perhaps even brutal scrutiny. This was not to be.  Instead of repeating the successes of the high-flying new generation of IT gurus made legendary by their historically brilliant application of IT during the political campaigns, America got the same-old, same-old IT project failure scenario.

Why?  How?  Who?

 In this blog space I want to explore both the nature and behavior of organizations and the people inside of them when building automated systems.  Why do (we) IT and management professionals fall into the same 40 year-old traps?  How and why does management miss or ignore warning signs?  Who makes up the typical team – and does that contribute to this apparent blindness?

 Since 1963 I’ve worked in what I’ll call Information Technology. Back then it was called Automated Data Processing (ADP) and was punch card based (a term so old that spell check doesn’t want me to use it). The processing and logic was split across different machines (one for each function) each having a unique hand-wired control panel for each step. All of the technology has changed drastically. What it took eight of us to do on a dozen machines back then, can be done by one person on an iPad today   What hasn’t changed enough is the ability of organizations and the people in them to consistently apply proven methods in building systems.

 This blog is dedicated to exposing these issues more fully in the hopes that someone will learn something that will help avoid the mistakes that continue to plague IT projects in particular.

Healthcare.gov and Irrational Optimism

On Nov 19, 2013, 50 days after launch of Healthcare.gov, a ‘red team’ report by McKinsey was made public.  The (undated) red team report, was apparently briefed to White House, HHS, and CMS officials in April.  The briefing addressed several areas of the project, but one set of observations in the 14 page briefing that struck my interest is the part that compared an ‘ideal situation’ for projects of this type to the ‘current situation’. The current situation was described as having:

• ·      Evolving requirements
• ·      Multiple definitions of success
• ·      Significant dependency on external parties/contractors
• ·      Parallel “stacking” of all phases
• ·      Insufficient time and scope of end-to-end testing, and
• ·      Launch at full volume 

In the systems engineering world, these are among the deadly sins of projects:

• ·      No technical target          (specification ambiguity)
• ·      No project goals              (scope creep and confusion)
• ·      No single authority          (managerial chaos)
• ·      No proven methodology (technical chaos)
• ·      No time                           (mandated 'big bang' date)
• ·      No live testing                 (everything must work for everybody on day 1)

So, what happened in the five months between the red team’s diagnosis and launch?  One politically oriented notion is that those closest to the President understood the risks and decided to ignore them or not raise attention to them. A technically oriented notion is that they didn’t understand these serious risks, or anyone’s ability to actually mitigate them.  In either case, 'everyone' involved seems to have suffered critical, if not fatal, cases of Irrational Optimism: a belief based on something other than rational thinking.  This kind of magical thinking includes hoping that the diagnosis was overly critical, hoping that the teams would "fix it", and hoping that history would not repeat itself. 

What else could make the apparent optimism even more irrational?: The need to service, organize, interface and/or manage:

• ·      17,000,000 users
• ·      55 contractors
• ·      9 government agencies
• ·      36 states depending on the federal system
• ·      14 states building their own exchange
• ·      170 insurance companies
• ·      4,500 insurance plans

On December 1, 2013 we will discover whether this system development project team can redeem themselves of the MAJOR DEADLY SINS committed.  Can they ultimately avoid being added to the list of FEDERAL FAILED SYSTEMS PROJECTS? 

We’ll be watching, analyzing and reporting.

Humans, Organizations and Failed Systems

What human behavior in organizations contribute to problems in implementing automated systems: 

Here are some of the ideas the blog will discuss in the coming weeks. 

• Willful Gullability
• Irrational Optimism
• Executive Impatience
• Defying the laws of Projects: Requirements Creep: schedule, project management, contracting, cost estimation, software development life cycle, testing, deployment, sustainment, and reporting)
• Willful Suspension of Logic & History
• March to the Tune
• Mistaking Cheerleading for Substance
• Fake Stoplight Charts: liars, damn liars and bogus pretty charts
• Lying by Scorecard: “We Can’t Show The Executives All These Red Scores”
• Who Needs Lengthy Analysis?
• True Believers vs True Thinkers
• Whistling Past The Graveyard of Failed Easy Answers To Complex Problems
• The Light At The Beginning Of The Tunnel
• On Sausage Making
• You’re Just Being Negative
• Arrogance of Personal Abilities
• Ignoring The Obvious
• Down The Rabbit Hole: Alternative Reality
• Top-Down Thinking In A Bottom-Up World
• Project $hell Game$$$
• Lemmings & Teams
• Don’t Let The Truth Interfere With A Good Story
• Criminal Misdiagnosis

Healthcare.gov system: how could it go so badly?

Project management professionals and pundits long-ago described PHASES of projects as:

1. Wild Enthusiasm

2. Disillusionment

3. Panic and Hysteria

4. Search for the Guilty

5. Punishment of the Innocent

6. Praise and Honor for the Nonparticipants

I suspect that the CMS Healthcare.gov project is currently in phase 3, and will move to phase 4 on December 1 when we all discover if the panic & hysteria paid off with a good-enough website and adequately functioning backend subsystems that feed it.

But how could such a high-profile system (POTUS bet his presidency and legacy on it) go so wrong, with so little warning before "DAY 1"?

This blog will focus on the many, many reasons that projects…. particularly Information Technology-based projects fail so often.  The Standish Group publishes the CHAOS REPORT each year that provides insight into IT project failures in small, medium and large organizations.  The larger the organization, the higher the failure rate.  Standish has reported that ~30% of projects get cancelled before completion; ~50% overrun their budgets by ~200%; while only ~16% of projects are realized on time and on budget.

Follow this blog for more exploration of contemporary human - automated system struggles.