Blog Insights
Taking the Stress Out of Your Launch, Part 2: the Launch Phase
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.
As your website’s launch date is right ahead, you’ve ready to put the final touches in place, line team members up for their parts, and tee-up the exact processes to make introduce your new platform to the world.
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:Launch window
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.Launch team
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 has gone live. Who will do these? Think about the skill sets, context, and perspectives needed to get a good review done quickly.
- Analytics: Who will be checking to make sure data is being collected correctly once the site is live?
- Communications: Who will be in charge of making these happen? See below.
Communication plan
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.” 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.Fallback plan
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.Launch
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!After launch
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, before handing off to the team best suited to handle maintenance and support. 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. A good place to start when defining that criteria is that issues must be both critical and urgent – and then determine what “critical” and “urgent” mean for this project. Referring back to your definition of success or your measurement plan can help.The takeaway
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, iterative 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.
