If you don’t think QA is important, then you haven’t been paying attention. RE: The health care exchange launch.
Now, a heads-up: I don’t know the intricate details of the launch of healthcare.gov. My assumptions are based on the facts I’ve heard and my experience. And this post isn’t related to the politics of healthcare, but instead the launch of a website. OK, disclaimer completed. Let’s roll.
Sadly, most websites launch without a QA plan.
The IT teams that manage the website? They usually have no protocol for how the site will be checked for functionality.
Marketing teams ask about it, but don’t really understand the complexity of QA processes.
And worst of all, most agencies have no structure past “OK, go find bugs!”
Yes, you read that right. Most agencies rely only on dreams and magic for the site to launch. And certainly don’t plan for the unknown.
My car’s shifter was acting funny and when I took it in, I told him my issue, and he told me that he needs a tech to look into it before he can identify what is wrong. He had a hunch on what it might be, but asked I don’t hold him to it until they dig deeper.
He project managed me, folks! He told me the possible costs, the timing, and what it would take to understand, isolate, and fix the issue. It’s not like I didn’t have to pay for the diagnosis (shifter cable was twisted) and then pay for the fix (new shifter cable diddly-wopper).
Essentially, our mechanic has a better protocol to manage the expectations of the unknown.
It's time for the project manager to represent the team appropriately and say early in the project (at kickoff, or even during scoping): It is not ready for launch. We need more time.
I listened to the testimony of one of the contractors for healthcare.gov. When asked if she flagged this possible delay, she said it didn’t sound like that was an option. Are you kidding me? The site isn’t functional and let’s face it: It’s taking the same amount of time as if she would have brought this up. So in the end, she looks disorganized and the user can’t make a transaction on the site. Ugh. Been there, done that.
It makes our entire industry look bad, really. There have been many times that I’ve been deep in a launch that some weirdo thing is happening on the site, and we can’t figure out why. And every time, I’m honest with the expectations and say the following:
“We are in QA. Bugs are just that: Bugs. It is impossible for the team to be held accountable for exact timing of when we will have a definitive fix for the issue. Right now, we are looking to isolate the issue within the next 24 hours, and then I’ll communicate the plan of how we fix the issue.”
And we ensure we have plenty of time to start QA cases to isolate bugs. And also ensure the QA process is slickly managed within the right lens of content, creative, and functional. More on that in another post.
Procedure is half of the solution. We need to educate our clients on the reasons why these things take time, agree that they can be complex and ensure they aren’t complicated. Help them understand that it will take time, and to be sure that they understand why. Ensure that a stable site is way better than aiming-for an unrealistic deadline. Call a meeting with the primary stakeholders (your marketing manager, IT manager, dev lead, UX lead, and design lead, usually) and start the conversation.
It will start a little something like this:
“As I mentioned to <insert primary stakeholder name> on the phone, I wanted to get everyone together to talk about expectations for launch. I pulled up the schedule and we should talk through what we think of the timing and relate it to the launch date, the 15th. Please help me realize what we could work on that might help us trim time, or help extend the launch throughout 3-4 days to make sure all is working right.
It is important to my team that we guarantee a stable experience for the user. That is of the utmost importance, and let’s chat about how we can ensure that this is realistic.”
And let everyone talk.
No one will say “No. I want to be sure the user can’t complete that form. Screw it” or “You mean to tell me we can’t launch by the 15th? You are fired.”
They will respect you for calling this out early in the project (once again, around kickoff) and letting them come up with compromises that they feel are appropriate. If you are bringing it up DURING QA or DURING launch, then you created your own mess and you’ll have to clean it up. May the force be with you on that one, because you're probably going to get eaten alive.
With what happened with my car, I trusted my technician and my advisor. And your team will trust what you have to say as well. He’s the subject matter expert (I know nothing about that shifter thingy) just like your marketing manager doesn’t understand why Firefox won’t show your video play controls in IE9. And look at the dominos falling about healthcare.gov. Messy? To say the least!
Lead them. Be honest with them. Educate them. Do better, dammit!