Taking the Stress Out of Your Launch, Part 2: the Launch Phase
This is a continuation of my previous blog post, “Take the Stress out of Your Launch Before You Even Get Started” on how to plan ahead for your website launch, meaning what to think about before you start the project and what planning to do at least a month prior to the launch.
If you have not yet read my first post, I recommend starting there. If you have, read on!
A Week Before Launch
By now, everything should be built, and testing should be complete. Your team should have also by now pinned down the following:
If the launch is going to be mostly invisible to your end users and the technical risk is low, best practice is to release early in the week and during regular business hours — preferably early in the day. This gives you the greatest opportunity to adjust since you will be fully staffed and can pull from your tech resources if something goes wrong.
If the risk that the launch will impact your end users is moderate or high, take a look at your site analytics to see what times of day your site typically has low traffic. If, for some reason, you have to take the current site down in order to do the release (also consider if you need to give your end users a heads up about the launch in this case), then pick a start time right when traffic typically ramps down. Also make sure that your launch team will be available for at least a few hours longer than you expect to need them.
Your launch is not just about all the technical steps needed to release, though those are clearly important. You should also consider:
- Third-party tools: Are you reliant on external systems such as payment gateways for donations, hosting providers, external data sources, etc.? If so, let them know about your upcoming launch and make sure you have the phone number of someone able to help troubleshoot immediately if something goes wrong.
- Testing: Both during and after the launch, at a minimum you will want to do spot checks to make sure things are in fact running correctly once it is live. Who will do these? Think about the skill sets, context, and perspectives needed to get a good review done quickly.
- Communications: Who will be in charge of making these happen? See below.
There are two big parts to this: internal and external communications. External communications tend to be more obvious, e.g., press releases or notifications to your users. For internal communications, think back to the list of “who really cares about your site launch” (from my first post). The people waiting anxiously, wondering what’s going on, are going to be a lot more pleased and calm if you keep them apprised of what’s happening throughout the launch.
If something goes catastrophically wrong, what will you do? If you have to make that decision in the moment, it will inherently be a hasty decision. Having a contingency plan in place beforehand mitigates this and alleviates stress during launch. A fallback plan should include both what to do and when to “call it.” A solid standard starting point is to revert to the pre–release state and reschedule the release – no sooner than 24 hours from when you call it – so the team can troubleshoot, fix, and test the changes. How much time the team can spend on an issue before making use of the fallback plan depends on the impact; what it means to stay in the partially–released state. For example, if the site is down while you troubleshoot, then you can’t take as long before you call it.
Breathe! By now you and your team should know what to do, have everything in place, and be able to adapt around unexpected bumps. Your stakeholders should also know what to expect so you will have some grace. Focus on keeping your stakeholders informed as the launch progresses —and be prepared to celebrate!
The work is, unfortunately, never done. Despite all testing and reviews, it is safe to assume something will not be spotted until it's in front of real users. So be sure to plan for that! Clearly communicate where and how issues should be reported, and know who needs to be involved in triaging and prioritizing issues as they come in. Even better, plan for a small release a week or two after launch, and potentially a few more after that. Knowing there is another release window coming up makes post-launch fixes less stressful.
Finally — and this can be hard — be very, very judicious about making urgent emergency changes! Quick changes are much more prone to error. It can help to define some criteria ahead of time around what is worth that risk and get your stakeholders to sign off on those criteria ahead of time.
You cannot plan for everything, but not planning at all is worse. There are many other activities you may find helpful or necessary for your particular launch, but the above are simply the core items from my experience. The thing to remember though is that the key to a successful, low–stress launch is collaborative planning. That is how you:
- uncover the unexpected so you can adjust course ahead of time,
- build in the breathing room to adapt as needed; and,
- build the shared trust and expectations so you can weather those bumps and come out stronger.
Plan ahead so you can go into your next launch confident — and come out of it celebrating!