It’s impossible for anyone outside of the HealthCare.gov project to truly assess what went wrong, but being in the interactive technology space, and understanding the kinds of problems that plague this work, gives me a unique perspective from which I think I can make some assumptions. A lot of people have been talking about the site; for me, it’s an opportunity to reinforce an important lesson I’ve learned after working on hundreds of technology projects: the key to a successful project is a process that facilitates honest, open communication.
When it comes to learning lessons from this extremely tough situation, blaming an agency or individual is unproductive. And it’s potentially inaccurate. What I want to focus on is a common bad habit around communication within a project — more specifically the bad habit of not telling the truth. I do this not to point fingers, but as a call to action to do projects right.
After reading articles and watching the testimony in front of the House Energy and Commerce Commission (none of which provide much clarity or transparency), this calls to mind the all-too-familiar mistakes that are often made around how the initial partnership was established.
The basic structure of the project mirrored one that digital agencies everywhere are familiar with: the Centers for Medicare & Medicaid Services (CMS) was the client and CGI Federal was the (primary) agency. There is a traditional way that clients approach these partnerships, which brings with it a process in which telling the truth isn’t valued. We’re in the ‘service’ business. The traditional attitude around ‘service’ is pretty straight-forward: a vendor delivers absolutely on a request. But our business is not a traditional service business in that it requires collaboration, trust, and a process for delivery. Honest, truthful communication is the foundation of any reliable process (note – I’m not falling into the trap of judging the process itself. Whether it was agile or waterfall or some combination of the two – a process will fail if dialogue around it isn’t real/honest.)
Process has to facilitate a partnership in which two-way communication is possible. A project that doesn’t allow or encourage the agency to be honest about what’s possible, what’s not, and what the best solutions are given the real parameters is a doomed project. From the outside, it appears that a handful of truths were not told.
You’re giving us the wrong information. It’s typical for clients to bring a solution to the table, rather than a set of problems. Not only do they believe they already know exactly what they need, they have a set of limitations that include a dollar amount, a timeline, and a set of features. I feel safe in assuming that CMS came to the table with a full-meal-deal set of expectations and set a day on which it all had to launch. But that collection of information didn’t necessarily solve the problem. In fact, agencies are in a much better position to produce a successful solution if they understand the core needs, questions, and requirements. Then, together, with the client, they can create a scaleable end-product that fits both the needs and the constraints. You can launch on your launch date. But you might have to ask the question – ‘Do you want it to launch or do you want it to work? If your only priority is the launch – you’re missing the point. If you want it to meet the needs of the end users by the launch date then you might have to scale back initial launch requirements. That’s not a bad thing if on launch date you are making people happy vs making them angry.
The feature set is unrealistic. CGI testified that one of the main problems was that there wasn’t enough time to adequately test the site before launching. Testing wasn’t the problem, though, it was just a symptom of a deeper issue: they tried to develop a feature-rich site within an unreasonable timeline. In fact, testing technically starts on day one. Writing the test plan — over time against a set of realistic features that fall within a realistic deadline — could have actually helped determine just how unrealistic the features were and help support effective changes.
Money can’t solve this problem. The project had a substantial budget, but money can’t make things go any smoother than the set of limitations allows. I’m constantly reminded of the fact that more bodies and minds working on something don’t necessarily make it better. You need the right people focused on the right things. (For example: 12 surgeons working to save a life won’t necessarily succeed; one skilled surgeon is all it takes to do it right.)
Ultimately, it seems like there was an inability for the agency to tell the truth about these things from day one. There was a lot at stake in this project — politics, reputation, money — and as a result, a precedent was set: the firm was simply going to do what they were told. This dynamic leads to an onslaught of side effects: overpromising, mismanaged expectations, and silence in the face of it all. Here’s what could have happened: someone on the agency side should have said, “We should roll out a limited set of features to start, and adequately test the additional features, so the that site will function the way that the end user will expect it to.” And if that was said, it should have been heard.
The traditional approach failed these teams: they walked in the door and put their terms on the table and the firm said, “we will do that.” It seems no one level-set, or reset, expectations along the way. A good process, one in which teams are at the table together, allows for honesty.
In the end, it’s never worth compromising an effective process. Neither bodies nor money replace a process in which partnership, honesty, and the end-user are all valued more than a deadline.
If you want to know more about our process, we wrote a book about it. Check it out.