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 dpacker@xby2.com.

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.

Register or login for access to this item and much more

All Digital Insurance content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access