I have been following the rollout of the federal governments HealthCare.gov website and the subsequent healthcare exchanges. I have been reading many articles outlining the challenges that the team has faced with such a massive implementation, in a limited timeframe. There are many lessons to be learned from the HealthCare.gov story, but I would like to share three take-a-ways that struck me as important for EVERY software deployment, no matter how big or small.
Lesson #1 – Good, Fast or Cheap: Pick Two
It would appear from statements made from both HealthCare.gov contractors as well as the secretary of health, that there were a number of issues that should have either held back the deployment of the website, or a reduction in scope should have been applied, and possibly, additional team members should have been added to the project.
This reminds me of a simple project management quote:
“We can make it good, fast, or cheap. Pick two.”
Expert project managers know that very few real-life projects stay on track throughout the entire project cycle. A good project manager also understands how to make all three project constraints adjust to each other in order to maintain project quality. Some of the methods to keep projects within constraints are purely political: preventing stakeholders from changing the scope and maintaining boundaries around financial and human resources. Other solutions require classic project management techniques: keeping team members focused and adjusting milestones when necessary.
Lesson #2 – Loosely Couple
A quote I continue to hear from those responsible for the HealthCare.gov support and management is, “we keep fixing problems with the site, only to uncover a larger problem with the next step in the process.” Such a simple statement implies so much about the design of the site, and its architecture. It implies that the site was built with a tightly coupled architecture.
Many solutions continue to be built in a tightly coupled fashion for a variety of reasons. Some architects and developers just don’t know any better, they’ve never been exposed to or experienced what exactly people mean by “loosely coupled” software. Still others see creating loosely coupled software as another layer of complexity that they just don’t need inside of their applications. Still others have seen and experienced loosely coupled solutions, but still don’t understand how to implement it effectively.
If constant and diligent thought into how systems and software will interact (and how it can be separated for testing or for replacement) is not done then we will end up with a jumbled mess. We have to be constantly evaluating our systems in order to keep them in check. Software systems become unmaintainable because we let them grow on their own, without keeping an eye on how that growth is proceeding until one day we realize that our solutions are a tangled mess of copied code and interwoven dependencies.
The very nature of loosely coupled code and services is to prevent this exact issue. Building and deploying applications using a service-oriented architecture provides an environment for loose coupling between components. The benefits of loose coupling include location transparency, protocol independence, and time independence.
Lesson #3 – Don’t deploy without proper testing
As early as June of this year, individuals close to the HealthCare.gov website had warned HHS directors that there was not adequate time to test all features and functions of the rollout. This included, not only the website and its various components, but also the data exchanges between the federal site and the state insurance exchanges. Not to mention that as late as September of this year, one month before the scheduled launch of the site, top HHS management changed a key requirement to the functionality of the site and the exchange process.
The importance of software testing and its impact on the software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specifications, design, and coding. The greater the visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing.
It is not uncommon for a project to allocate as much as 40% of its efforts on testing. Yet for many, testing is often an afterthought.
You don’t have to have such a high profile software solution as HealthCare.gov to have to implement these best practices, they can be applied to any software solution from Mobile to Cloud , Portal to CRM and more. The keys to a successful application begin with :
- Project and scope management
- Loosely coupled software and services
- Complete and thorough testing
