The Obamacare rollout continues to teach excellent lessons on how not to implement a large complex program. Since it went live on October 1, the federal government’s new Healthcare.gov website has been plagued with problems. Many people have had trouble finding the information they need about new health insurance options under the Patient Protection and Affordable Care Act; in some cases, users haven’t been able to access Healthcare.gov at all. The website can’t handle the huge influx of traffic (in just over three weeks, it’s seen over 19 million visitors and counting!), and its backend code is riddled with errors and bugs that have created headaches galore for users.
How did this happen? In the wake of the site’s launch, there’s been a lot of fingerpointing from the media, program administrators, politicians, and the general public. As full investigations get under way, it’s becoming increasingly obvious that Healthcare.gov’s problems are the result of lots of unconnected contractors working on one giant piece of software separately and without strong guidance:
[A] total of 47 different contractors worked on building Healthcare.gov, each tackling different pieces of the site’s functionality. The result: a fragmented system, with no easy way to figure out who messed up, where. (Adam Bluestein, “Business Lessons From The Botched Rollout of Healthcare.gov,”Inc.)
Clearly, the people in charge of this project forget that “keep it simple” is usually the best solution. When multiple parties are trying to build something with many different tools—and they don’t all have a clear idea of what the result is supposed to be—well, it’s no wonder that website has a few problems.
In the article quoted above, Adam Bluestein writes specifically about how tech companies can learn from the Healthcare.gov rollout. But this scenario yields business lessons for pretty much any other industry, too.
Staffing companies in particular can take a page from the “what not to do” handbook of the Healthcare.gov launch. For example, many companies to have a strict division of labor: sales reps secure an order, then pass the job specs on to recruiters for fulfillment. Once the handoff is complete, many sales reps consider that job closed and move on to the next client or prospect.
The problem with this approach, however, is that salespeople who don’t follow a deal through to the end miss opportunities for quality control. Because the sales rep is the one who worked directly with the client, she’s the one who has the best knowledge about what the client wants. She’s responsible for communicating all the specs to the recruiter—and she’s in a unique position to know whether what the recruiter is doing matches up to what the client expects.
With tons of job details to keep track of during the sales-recruitment-hire process, it’s easy for something to fall by the wayside. Fortunately, it’s also easy to make sure that doesn’t happen.
Sales reps don’t need to micromanage recruiters, but they do need to remain vested in the candidate-search process to make sure their clients get what they need. Recruitment entails a different skill set than sales, and salespeople should rely on recruiters’ expertise in this domain. So sales reps should sit back and let recruiters take over once the job specs have been passed on. But sales reps should also lean forward every once in a while and peek over the recruiters’ shoulders, just to make sure that all the ducks are lining up in a row as they should.
Over the next several months, as the Healthcare.gov website gets analyzed (and, hopefully, fixed!), I’m sure we’ll see plenty of articles about what the business community can learn from its launch. This cautionary tale already has one clear lesson for staffers, though: if you make a sale, make sure you follow that job until its completion so you can ensure the quality of the placement.