A Week Before LaunchBy now, everything should be built, and testing should be complete. Your team should have also by now pinned down the following:
Launch windowIf 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 teamYour 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 planThere 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 planIf 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.
LaunchBreathe! 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 launchThe 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 takeawayYou 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.
Forum One’s web design and development experts work closely with some of the world’s most influential missions to ensure their websites are developed and launched in order to create impact. If you are looking for support on all or some of your launch plan, we’d be very happy to talk through it with you.