No matter how well funded, no IT project has unlimited resources, money or time. And that includes even the most high-profile government-sponsored website today, Healthcare.gov. In recent days there has been a lot of finger-pointing about the glitch-plagued site, but here’s one thing everyone can agree on: No one is happy with it.
While government leaders are busy faulting the contractors who built the site, contractors have been quick to try and shift the blame to last-minute decisions made by senior administrators in the Health and Human Services Department. While the ultimate source of the failures is still being hotly debated, there are at least a few lessons consultants and companies can learn from this disastrous situation:
1. You don’t get a second chance to make a first impression.
When your organization launches any new application or system update, it’s effectively telling users, “This will make your life easier.” So if you are asking users to dramatically change or adopt a new way of doing things, whether it’s choosing a mandatory healthcare plan or adopting new sales reporting procedures, you have to ensure it will be easy to use and deliver on its promises. Otherwise you may find yourself launching a damage-control campaign on top of fixing a broken system.
2. Don’t wait to establish a clearly defined testing team and strategy.
Healthcare.gov is certainly not the only website to suffer from the pressure to launch under an extremely tight, or even impossible deadline. Having a testing team working in tandem with the development team on every phase of the project can help identify and resolve issues before they escalate to the final release. But more importantly, you need a thorough testing strategy in place to define what needs to be tested and how it will be executed.
3. Assign and clearly document testing responsibilities.
The entities involved in the Healthcare.gov website launch have been playing a high-stakes game of hot potato, with no one claiming ultimate responsibility for site testing. The point of assigning testing responsibility is not to be able to point fingers later, but to avoid confusion and project failure by ensuring all your testing bases are covered.
4. Listen to what testing is telling you — even if it’s not what you want to hear.
In any high-stakes project, you can’t afford to ignore the results of testing. Consider the fallout in public opinion alone over the problems with Healthcare.gov. Can your organization afford the financial costs of fixing a broken system after the fact? What about other costs that can impact your company, such as lost revenue and productivity, decreased employee morale, diminished shareholder value and other business risks? When you consider the consequences of pushing a launch date vs. managing a technology and public relations disaster, which would you choose?
In our previous blog post on testing, we explain why scenario-based testing can help organizations quickly isolate trouble spots and establish a team of experts who are highly experienced and familiar with the system being developed. That way, when problems do arise organizations can leverage this knowledge base to quickly identify and resolve issues — before they hit the front pages or the bottom line.
Healthcare.gov is already becoming a textbook case of “How Not to Launch a Website.” And a full investigation of the communication and technology breakdown is still forthcoming. But for now it’s fair to say that at least some of the problems with Healthcare.gov may have been avoided through best-practice testing methods, greater accountability among the parties involved and a willingness to listen to evidence of serious problems.
Does your company follow a testing strategy to ensure a successful rollout for new technology projects? Share your feedback in the comments below!
More Business articles from Business 2 Community: