How to destroy your brand in a few easy steps

Meanwhile, in the USA, the government has decided to provide us with a giant, neon parable about how catastrophic it can be when you don’t properly plan and execute your website project.

The New York Times has a piece (access to article free for a limited time) that describes the disaster that is HealthCare.gov, a website supposedly built to serve as a marketplace for all US citizens to shop around for health insurance - a site Obama apparently once promised would be as easy to use as Amazon.

As a project manager on web projects myself (albeit ones with budgets a little less than $630 million USD), reading this article gave me the biggest case of schaudenfreude I’ve had in a while. Here are a few key quotes from the article and, for those of you playing at home, my take on them.

And when I say “for those of you playing at home” I mean YOU. Yes, you, thinking about building a website - whether your budget is $600 million or $6000, these pitfalls are all too common.

[The project] was flailing in part because of the Medicare agency’s decision not to hire a “systems integrator” that could coordinate its complex parts.

This one is a no-brainer. Whenever a client comes to us with integration, an alert triggers a flashing yellow light in the office, calling in our integration expert from his secret lair. Integration is never “simple”. Any time you’re plugging your core data - be it your product database or, say, health insurance plans from hundreds of brokers - into your website, be prepared to take it slowly and carefully, quite probably with some experts on your team. And don’t forget lots of testing. Which reminds me…

The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered. Fixing the account creation software simply exposed other problems; people still could not register to buy insurance. A system intended to handle 50,000 simultaneous users was fundamentally unstable, unable to handle even a tiny fraction of that. As few as 500 users crippled it, according to people involved.

Even while feeling sanctimonious in my schaudenfreude, I winced while reading this. Testing is always critical. Let me say that again: testing is ALWAYS critical. For performance, for basic functionality. For back (integration!) and front (user experience!) end.

Apparently they considered taking the site down to fix, but according to the engineers working on this, “the website needs to be up to see where the problems are”. While obviously I don’t know the finite detail on how this system was built, testing in a testing environment that can replicate the production environment is pretty damn critical too, while we’re at it.

But what’s the root cause of all of this? I don’t mean of the problems - clearly, a lack of testing was the major problem, as it meant that meant the site went out to the entire US population full of bugs. I mean why wasn’t it tested?

In my experience, breakdown of basic website project processes often point to key stakeholders not understanding the importance of sticking to the process - and more often than not, sticking to process means committing to quality over time and money. I imagine the President of the US must be a difficult client to manage, though it seems Obama himself was in “an insular White House that did not initially appreciate the magnitude of its self-inflicted wounds” and so perhaps not keeping as close tabs on the project that had the potential to make-or-break his presidency as he should have been.

And that’s a scenario that scales down effortlessly. Head of a company? Care about your company’s image? Care about your website project.

But the article hints at more toxic sources of the problems:

Relations between the [different contractors] had soured over the summer, well before the website opened… Contractors responsible for different parts of the portal barely talked to one another, hoping to avoid blame.

Blame. Alarm bells went off as I read it. If your team is scrambling to assign blame instead of take responsibility, something is wrong with your management of the project. People who look to assign blame are afraid of repercussions. People who take responsibility feel safe enough to admit mistakes and subsequently work to fix them. And if they’re the latter, guess what? You find out about problems and are able to resolve them before ruin your presidential career because of them.

Don’t be that guy. Focus on finding out how to fix the problem, not on crucifying those who caused the problem.

Which brings me to my final point…

Hubris is one of your biggest enemies. Don’t underestimate the need to invest in the right people for the job, and to actually exert some effort to understand the job they’ll be doing. These people know what they’re doing better than you - that’s why you hired them. And doesn’t the project deserve the best? Your website is often the first thing people see of your business, your primary selling point. It’s on the front-line of defending your brand. Underestimating this could spell your doom. As Obama says:

”We created this problem we didn’t need to create. And it’s of our own doing, and it’s our most important initiative.”

Shakespearean, isn’t it?