I received a number of comments on the “Lessons Learned from the HealthCare.gov Rollout” piece featured on npENGAGE late last year and wanted to follow up. Apparently a lot of work has been done to make the system better, and there has been no shortage of Monday-morning quarterbacks (like myself) trying to make sense out of the project and its failings. I was tempted to let a sleeping dog lie, but then HealthCare.gov gave my computer the Blue Screen of Death not once, but twice while researching this piece and I took that as a sign that there was more to learn here. The same disclaimer applies as before: Hindsight is always 20/20 and this commentary is intended for informational and (hopefully) educational purposes only.
Leadership of Technical Projects
Clay Shirky wrote a very popular analysis of the forces and personalities at play in a technical project. Notably, the over-optimism of non-technical leaders when assessing project risks and lack of understanding of the triple-constraint model. In a nutshell: projects are constrained by an interrelation of scope (or quality), timeline, and resources (costs). Changes to one of these constraints will inevitably impact the others. In this case, leadership chose to maintain commitment to a go-live date (timeline) despite red flags from technical staff and outside experts (a good summary here and the full must-read deck is here), resulting in poor quality (scope) and high costs. Mike Reardon has a good piece on a related topic, in particular the sharing of information between different silos and layers within organizations, and the temptation to willfully avoid difficult decisions. The lesson learned here is that leaders need to understand the realities of technical work, including technical feasibility, project constraints, and risk mitigation, or be prepared to live with the consequences. It seems that the choice made here was to complete testing in production after go-live, and rather than risk delays to launch, which made the ongoing quality issues inevitable.
Impacts of Software Bloat
In my last piece, I noted that the HealthCare.gov site has “500 million lines of code“, much of it likely integrates to diverse back-office systems, and the impact that will have on ongoing costs related to troubleshooting and maintenance. One other impact: Accenture is now taking over the maintenance contract for the system from the original developers, CGI Federal. The Accenture team will have to ramp up and make sense of this bloated system and the costs in terms of knowledge transfer, documentation, and work effort will be astronomical. I can only hope that the system has been documented effectively, although I have my doubts. More on the topic of effective and usable documentation in another post.
Exception Handling
Modern websites aren’t just a website – they inevitably involve capture and processing of data, integration with other systems and databases, and back-office business functions. Unfortunately, many (30-40%) of those backend components of the HealthCare.gov system were not yet built and are likely going to be built over many months to come, meaning administrative users didn’t have a means to troubleshoot, address errors, handle exceptions, or carry out simple customer service requests like information updates. Websites are known for collecting bad data from non-technical users who, say, type with two fingers or don’t proper case, as well as from problematic integrations between different platforms, and this approach is another example of trading timeline for quality. Due to the integrated nature of the system, integrations from HealthCare.gov has the potential to propagate data integrity issues to other systems, creating a systemic problem and risk to all systems involved.
Active Partnership with Vendors
Not every project is or should be a partnership, but a project of this scale requires an active and very involved partnership with mutual commitment, investment, involvement, and governance. That will require effort, planning, and a willingness to get involved in the vendors development process as I’ve discussed previously.
Reverse-Engineering Quality and Security
Quality and Security have to be built into systems and processes from the beginning, not added at some point in the middle of a project or at the end (yikes). The impact of this type of oversight is exponential: See this analysis suggesting that HealthCare.gov may need to be rebuilt with security in mind. Other thoughts? Please leave a comment.
No comments:
Post a Comment