Editor's Note

After HealthCare.gov, 5 questions worth asking

measurement tool

Look on the bright side: Thanks to HealthCare.gov, IT procurement, enterprise architecture and project management are the talk of the town.

Granted, the conversations are uncomfortable for the agencies and contractors involved in building the site, but as the crisis coverage subsides, a real opportunity exists to use this attention to actually improve the system.

I won't presume to prescribe those improvements. The story is still unfolding, and there are (many!) others with deeper expertise and experience to craft the answers. But these questions should be part of that conversation:

1. Who should be the integrator?

The fact that no contractor was the clear lead for HealthCare.gov has been flagged as a critical mistake. It's not clear the Centers for Medicare and Medicaid Services actively chose to play the role of systems integrator, but this was the result in practice. Is that ever a good idea for complex IT systems? And if so, where is the line that agencies dare not cross?

2. Can agile help everywhere?

Advocates of agile development argue that rapid iteration improves the odds of success and that opposition within agencies is largely cultural. But when a project's key parameters have been legislated — or when politics make a pilot program impractical — can agile make a measurable difference?

3. Are the best vendors bidding?

Open-source proponents and experiments like RFP-EZ suggest that agencies can get more value by working with firms that have been scared off by FedBizOpps. When do federal procurement requirements demand experienced contractors, and when do they merely drive up the costs?

4. Do agencies have the right people?

Do procurement officers know how to write a statement of work — and outcomes — for complex systems? Are project managers talented enough to ensure that a lowest price technically acceptable contract truly stays technically acceptable? And can agencies develop straight-up IT talent to build systems in house and steer projects that will be contracted out?

5. Can you trust enough to share?

HealthCare.gov relied on real-time queries of multiple agency databases and put signups at the mercy of a slow response from any one of them. How can agencies embrace APIs and shared services while still taking risk management seriously?

About the Author

Troy K. Schneider is editor-in-chief of FCW. Connect with him on Twitter: @troyschneider.

Featured

Reader comments

Wed, Nov 13, 2013 Jaime Gracia Washington, DC

Therein is the real change agent; culture. Until government realizes that the typical "waterfall" approach to technology acquisition and execution is doomed to fail, we will repeat healthcare.gov again, less the politics. We will continue to write junk requirements that make no sense, have no idea what outcomes should be, make dozens and dozens of amendments to RFPs, and finally award a contract after so much time that the requirements are out of date and meaningless. Now comes modification after modification because of LPTA... "Big Bang " projects simply do not work, given its track record of poor success time and time again (SAM, FCS, Deepwater, Virtual Case File, etc.). Agile approaches through realistic measure of capability, and thus baselined requirements for each module or sprint, is the path to innovation and success. The entire culture of federal IT is broken, and the root cause analysis needs to be conducted to understand that unless the paradigm is changed from "Big Business" to affordability, capability, and innovation, we will get nowhere. Keep wasting billions, and watching large contractors laugh all the way to the bank. Is anybody paying attention?

Tue, Nov 12, 2013 Robert Damashek Arlington, VA

In assessing the applicability of agile, I think it's very important to include the agile approach to planning and requirements - choosing sprints and increments that are both of value and achievable. Three twenty-something San Francisco programmers clearly proved this in the healthcare.gov space by choosing one key piece of the problem - finding applicable plans. The developers of healthsherpa.com did this in only three days using openly available data. By focusing on real outcomes of value to people rather than trying to boil the ocean (realizing the size of this ocean has been continually changing), the healthcare.gov team could have delivered the system in a series of practical increments, each of which worked and provided tangible value, and which were able to be woven together at a later time.

Sun, Nov 10, 2013 utopia27

You forgot to say "cloud" three times and pat Buddha's tummy. The real question is, "When does the culture of fear and blame abate enough to loosen the system, to allow success without evading and ignoring the system?" Current government IT does not have the right people in government roles, because they have all departed in disgust. Now the world is run by contractors, directed by distrustful stuffed shirts who don't understand what the contractors are doing. Government stuffed shirts are dogged by the feeling that contractors are moving from contract to contract collecting huge fees, desperate to stay one step ahead of blame for imploding systems. They govies are correct, and the govies know it, because they're doing exactly the same thing. It's a disgusting pad de deux allowed to continue because real leadership requires competence and accountability. The current (15 years...) dynamic from the politicals and congress demonizes accountability, and punishes any genuine leadership.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above