With tomorrow’s pending October 1 go-live date for the health insurance marketplaces mandated by the Obama administration’s Affordable Care Act, the IT industry has been abuzz with speculation that a project so massive, built on such a short timeframe, is bound to fail. Recent delays in the small-business exchange underscore the challenge of product delivery.
As with many complicated IT projects, vulnerability lies in the testing phase:
Charlene Frizzera, president of consulting firm CF Health Advisors, notes that “Final security testing of the federal data hub, which links to databases maintained by multiple agencies and containing sensitive personal information, isn’t slated to happen until Sept. 30, one day before the rollout.”
“I have no idea what this thing’s going to look like on Oct. 1,” Rocky King, executive director of Oregon’s new health insurance exchange, said one afternoon last week as dozens of tense-looking programmers, scattered through the exchange offices outside Portland, rushed to finish testing and fix problems. “We could crash and burn and have to close it down.”
According to Patrick Howard, a lead consultant from Deloitte, testing for the new systems has been rigorous since as early as May, due to the overwhelming number of scenarios to test. “We’re talking about thousands and thousands of scenarios.”
Jama works closely with the Deloitte teams managing several of these state Healthcare Exchange systems. With projects like these, with hard delivery dates that have contractual, monetary or legal repercussions, getting testing involved as soon as a change occurs at any level, is extremely important.
Frequently QA is the last to know about any changes to the requirements and how they impact their test plan, and as development on projects gets faster and more iterative, the testing department faces increasing pressure.
Visibility into your test coverage and what is changing upstream, is how you make sure that there aren’t any gaps in your test plans – or your insurance policy to guard against your project going off the rails.
Traceability is difficult and manual with traditional tools like Microsoft Excel, and they weren’t ever intended to take into account iterative processes, thousands of changes or the decisions that led to them. This makes it difficult to know if your test plan matches up to the project deliverable that’s being tested. By having insight upstream, QA can ensure that they are testing the right things.
Collaboration, as enabled by Jama, allows the testing team to see the discussions and decisions around a given requirement or element they will be testing so they can accurately build and adjust their test plans to match. Additional value is added by capturing these cycles and changes and decisions through our collaboration and discussion streams.
The work Deloitte did on one project for the State of Montana, for example, had 5,000 test cases to execute to confirm the software system worked as it should and would meet Deloitte’s high standards of quality. The Deloitte team realized that they weren’t going to be able to work the old way—through documents, emails and spreadsheets. By using Jama, Deloitte was able to quickly validate requirements by effectively incorporating both client and team input. This led to the team being able to deliver a high-quality system that passed the test with the state, on time and on budget. (Read more about this project in this case study.)
The health insurance industry is undergoing radical change. Sometimes, having a hard and fast date like October 1 forces organizations to rethink how they work. And, as Deloitte has proven, that can be a good thing for product delivery.