Take the Stress out of Your Launch Before You Even Get Started
You’ve been working for months with your team to define and build a beautiful new or updated site. The text is written, the tests have passed, and now it’s time to put it out in the world.
Now what? How do you know if flipping the switch will go smoothly, or if you’ll be scrambling to figure out what went wrong? Unfortunately, the time to be asking these questions is long past, so let’s go back in time.
“In preparing for battle I have always found that plans are useless, but planning is indispensable.” —Dwight D. Eisenhower
Your launch is like a battle: it only happens once, in real time, there are many people and tools involved, and the outcome is extremely important. Chances are that things will not go as planned! But if you have planned ahead properly then you should have the right people, tools, and expectations in place to be able to respond quickly. That's the difference between a hiccup and a disaster.
Launch planning happens in stages; let’s walk through them.
Before You Start Your Project
Ask these three questions before you start:
1. Do you have to do one big launch?
Generally speaking, it’s less risky to release smaller changes, more often. And if you can, I strongly recommend it. But sometimes - be it for technical, political, or mission-related reasons - that may not be an option. So let’s focus on that riskier scenario.
Planning for those big, splashy launches, such as a complete site replacement or the announcement of this year’s set of highly anticipated reports, is a huge endeavor. This also applies to highly-sensitive releases that have to go just right, e.g., replacing the payment processor or your CRM.
2. Who is going to care on the launch day, really?
Who is going to want to know about your launch: media, social media, your return users? Do you have content contributors or outside stakeholders who will want to know how their work is represented? Is your boss asking you when it's going to launch?
Having an accurate sense of your key audiences will help you both set expectations ahead of time and put together a communication plan for the launch itself. This makes all the difference in how successful the launch feels.
3. How fixed is your launch date?
If there is a conference or event where the site will be announced, or some other extremely fixed date that this launch has to be ready by, that changes how much tolerance you have in your launch timeline. If it is extremely fixed, I recommend adding a week (or two! Or more!) to the timeline.
(At Least!) One Month Before Launch
It almost always takes more lead time than expected to prepare for a launch. You’ll want to identify dependencies and make sure everyone knows how much time is needed for each activity.
Timeline to launch
You and your core team will want to think through the activities needed leading up to the launch and timing for each. Work backwards from the launch, setting a specific date for each event. This will vary by organization and project, and will almost certainly involve more steps than the following simple example list:
- Content and code freeze: Before final testing, the product needs to be completed and stable.
- Final testing and reviewing: How much calendar time do you need to set aside to make sure these final reviews and tests can happen? (See QA plan below).
- Bug fixes and buffer time: Things are going to change, and you are going to find bugs or desired changes while testing, so plan ahead for that.
- Go/no–go: The last chance to postpone the launch if you need to make any changes – or to declare that it is good to go as–is. Think about who needs to make that final decision.
- Launch! The big moment.
- Post–launch: Changes or adjustments requested or needed post–launch (this will happen; trust me).
Note: You should expect this timeline to change as you get closer to launch, but this is a good place to start the conversation.
What types of quality assurance are going to be needed right before you launch? At the very least, your team should be asking questions such as:
- What stakeholders need to review and accept the website? This can both build internal confidence in the product and also identify possible improvements.
- Who needs to review the text and imagery on the website and how long is that going to take?
- What else needs to be checked? Who will be doing the final review to check if the site is accessible (see my colleague’s blog post about Accessible Design), to make sure the payment gateway is properly connected so users can make donations, or to make sure Google Analytics is receiving data? The specific areas to check (adwords, redirects, mailing list signups, etc.) depend on your specific project.
You may not need to have a detailed test matrix, but it is worth thinking through the areas of risk and how much effort it is worth putting into the last pre-launch checks, so you can go into the launch confident in the quality of what you are releasing.
Next: The Launch Phase
That brings us to about a week before the launch itself. Stay tuned for my next blog post where I will focus on those final stages.