Talking with the head of my account management team, I asked her if there was anything she'd like brokers to be more aware of. Quite emphatically, slapping her hand on her desk, she said that brokers need to include their software vendors in the benefits planning process. Also, she said they need to understand how important user acceptance testing is to the success of a technology project.
Apparently, she had just gotten off the phone with a broker who needed their employer group's online enrollment system configured for open enrollment. The broker explained to her that they had been working with the employer group for several months - choosing new medical plans and a new carrier, adding a supplemental life plan, generating new rates for all existing plans and expanding their eligibility groups. They went on to say that the employer was excited about the new employee communication plan that also went along with the year - it included posters, a kick-off luncheon for employees, customized benefits packets, an email campaign and an on-site vendor to assist employees with enrollment. She said, "That's great! And when is their open enrollment?" The broker responded: "Two weeks from today."
While this is an extreme example, she brings up valid concerns for virtually all software projects. First, the software vendor should be included in the planning process - this is important for proper project management for all parties. Second, my colleague's point about testing is one that often goes unaccounted for in an open enrollment project timeline.
Some brokers argue that since it is an operational system, it is the responsibility of the software vendor to make the configuration changes and test for quality assurance. While this is true, it does not eliminate the need for the end user to test the system. User acceptance testing is the last and critical step in a software project.
The test plan
UAT, as we refer to it in the business, should be completed before the system is placed into production. It requires dedicated participation by the end users and they should be using a test plan to guide their activities. The test plan will vary from system to system, but in general, the testing should be geared to provide adequate coverage of the functionality for all anticipated utilization by employees. Generally speaking, testing is based upon user requirements and specifications. For open enrollment, the specifications are the documentation that defines the plans, eligibility groups and tiers, rates and workflow - at a minimum.
As with any system, though, problems will be uncovered during testing. So, it is important to allow adequate time to fix and retest the problems and agree on the criteria for determining what will be (and will not be) fixed prior to pushing the software to production. Nothing is worse than going live and finding a slew of problems. As many reports have indicated about Healthcare.gov's problems, more often than not, inadequate testing is to blame.
Online enrollment projects are somewhat unique in the software world in that there are hard deadlines. In other industries software project schedules often slip, but we don't have that luxury. Start dates may be able to be moved by a week or two, but not much beyond that. In the end, the best open enrollment projects are those where everyone (vendor, broker, employer) takes the time to test the software configuration.
Lamb is VP and group head of the EbixBenergy business unit at insurance software company Ebix Health. Reach him at
