This is a two-part blog series focused on helping you feel confident and ready for your next website launch. “Part 1: Before You Even Get Started” explores the pre-planning phase, while “Part 2: The Launch Phase” tackles the immediate phases of the launch. 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 projectAsk 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.
Once you’ve kicked off the projectIt almost always takes more lead time than expected to prepare for a project launch. You’ll want to identify dependencies and make sure everyone knows how much time is needed for each activity.
Measurement planWhat does success look like, and how will you measure that? Defining this early helps inform the rest of the project work.
Timeline to launchYou and your core team will want to think through the activities needed leading up to the launch and timing for each. Work backward 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:
- Training: The people who will be editing the content of the site or otherwise managing it need time to familiarize themselves with what they can do and how to do it.
- Code freeze: Before final testing, the product needs to be completed and stable.
- Content freeze: the text and images also need to be completed and stable so you can confirm they work well together as part of your testing.
- 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).
- Handoff to support: Websites take maintenance and support over time – they are “free as in puppies”. Often the team best suited to handle that is different from the one best suited to design and build it, so plan ahead for what team will do that, how ongoing digital governance will work, and when to transition.
QA planWhat 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, to make sure the payment gateway is properly connected so users can make donations, or make sure Google Analytics is receiving data? The specific areas to check (Google Ads, redirects, mailing list signups, etc.) depend on your specific project.