Lessons from the Obamacare Website Debacle
Insurance Experts' Forum, December 19, 2013
What lessons can insurance technology and business executives cull from the troubled rollout of the Obamacare website? More importantly, why didnít the federal government and their IT vendor pay attention to the many painful lessons already learned by others?
Implementing large-scale systems that provide rich functionality, support thousands of concurrent users and handle high-transaction volumes is exponentially more difficult to implement than smaller-scale systems. Furthermore, the risks are much higher if that system is the way your customers will interact with you, especially when it is a matter that is both personally and economically significant.† †
For starters, teams implementing such mission-critical systems must put as much time and energy into testing and verification as they do into software development. The Obamacare developers didnít pay attention to early warning signs. The Obamacare website apparently failed even basic load tests prior to its launch, and yet the site was allowed to go live. If things donít look right on the surface, theyíre usually worse below the surface.
Did the government choose the wrong contractor? It certainly seems so, although itís always difficult to tell from the outside. Certainly poor decisions and bad execution happened, but itís hard to tell where the blame should lie. Sometimes clients set up projects to fail from the beginning. Sometimes vendors fail to do their part. And unfortunately, more often than not, both problems happen, which seems to be the case here.
Choosing a contractor is crucial and very difficult. Superficial analysis based on marketing materials, sales presentations and a few, prepared references wonít cut it. A more thorough analysis and selection process is needed. The people performing this analysis need to have the experience delivering similar initiates themselves, so they know what to ask and what to look for.
Furthermore, big projects like this should be staffed with the "A-Team" from the get-go. Strong project management and capable architects are incredibly important. The people in charge, on both the client and vendor side, must be visionaries, experienced leaders in business and technology, and not merely administrators of large government contracts.
How does one tell the really good project managers and architects from the pretenders, and how do you avoid the administrative project managers who add little value? Itís hard to tell the difference unless you are a strong manager and leader yourself. Strong leaders seem to have been in short supply on this project, as well as many other big IT projects in government and business.
If you have a strong project manager on staff or available, have him or her help you interview other project managers for key projects. That person may be able to help spot important strengths and weaknesses in candidates. If you donít have someone like that, do your best to pick project managers and architects who have a proven track record for delivering projects similar to yours. Donít just go by their resume. Talk to the key stakeholders for whom theyíve delivered in the past. If theyíre good, theyíll have a long list of customers who are happy to sing their praises.
Once youíve selected the vendor, stay close to the project and make sure you have a strong relationship with key executives from the vendor. Staying close to the project also means staying close to the deliverables produced by the project.
Successful projects typically use agile methodologies these days, and one of the key benefits of agile projects is that they emphasize working software instead of PowerPoint presentations and verbose status reports.†Ask to see the software demonstrated with realistic business scenarios on a regular basis. If your project team canít show you working software early on and canít continue to show the evolving system month after month, your project isnít going well.
Being able to escalate problems and concerns quickly is important. Projects donít suddenly fail. They fail a little bit every day, and the quicker you act when things donít smell right, the better. With your vendor partners, invest in relationships with the people who are calling the shots at the company.
When you need to escalate quickly, you want to make sure you can escalate to someone who has the authority to fix the problem. Finally, donít let a poor vendor or a weak PM try to convince you that the problems are too complex. If you have a good project manager and architect, they will make complex problems and solutions simple to understand. If they canít do that, youíve got the wrong people on the team.
Like investing in stocks, itís important to have a ďstop-lossĒ approach to your project portfolio. In the same way that good investors donít get emotional about their stock picks, good project sponsors donít get emotional about their projects. If the project shows progress and results, continue to invest. If not, make your best effort to help get it turned around quickly. However, if things continue to head in the wrong direction, halt the project before you look like the Obama administration.
David Packer is a principal of X by 2, a technology company in Farmington Hills, Mich.
Readers are encouraged to respond to David using the ďAdd Your CommentsĒ box below. He can also be reached at firstname.lastname@example.org.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on†www.insurancenetworking.com†do not necessarily reflect those of Insurance Networking News.
Add Your Comments...
If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.
You must be registered to post a comment. Click here to register.