healthcare.gov – It’s NOT about “Fixing the Web Site”

Many of us in Information Technology would love a crack at a CNN camera when it comes to the healthcare.gov debacle. I’m confident that we would make comments in areas around infrastructure, project planning, lack of proper QA, etc. However, the real culprit is not any of those things – sure, all that stuff may exist but the problem starts with lack of good requirements (read user stories), business process modeling and scope creep.

It’s interesting to hear that it’s all about “fixing the web site”.  Most of the time even conservatives seem to be repeating that. Some of the critics are starting to get it though.  It’s the ever-changing and confusing requirements. Let’s take a simple example with one narrow user story:

Applicant chooses “financial assistance requested”. Well, the level of financial assistance is tied to his particular situation right?  All of us involved in business process modeling know how complex that is – imagine the calculations changing while you’re building the project! Admit you scrum folks, you’ve “been there, done that”!

It’s kind of like asking a robotics engineer at Chevrolet to code an assembly for a new style of car without anyone ever manually putting the car together first. Let’s face it, they’ve not had time to do that – not three years, not even a few months. It’s said that business “administrative rules” were changing as little as a few weeks ago.

All this to say, “fixing the web site” is an infrastructure issue and that doesn’t address the real problem of knowing how the site should behave.

What should have happened?

Apply the “must have” rule. Goal #1 should be “streamlined reservation with minimal exception cases”.  Goal # 2 – send out generic categories of pricing for people as a start and then direct them to an entirely different resource for calculating assistance.  That would have made things highly less complex because all the registration and simple pricing could avoid all the logic associated with financial assistance.

They could simply get this answer “your insurance pool cost will be $92 per month, and your financial assistance will vary between $10 to $46 per month. Sign up now and your assistance will be calculated on a different day – or if you’d like to find out before signing up then click here to begin that process.” That link would take them on an entirely different infrastructure and set of business processes. Think about it – they never belonged together anyway (insurance pool quotes and calculating financial assistance).

Had they kept to the basics, they could have kept it simple and things would have been fine. They probably thought ‘we have three years so we can do it’ – but if the requirements don’t come until 27 months later than they fail from the start.

At this point I’d recommend doing major functional bifurcating and delivering the basics.  Actually I’m in the camp to kill the whole thing, to be honest – but if we’re stuck with it these would be my thoughts.  I actually have another health care plan that I think would be a great “offer and compromise” for both parties and I’ll write about that next – it’s actually very short, shorter than this!

-Patrick

Leave A Comment...

*