Four Ways to Make Launch Day Go Smoothly
In addition to guest posting on the UpCity blog, peaktwo is featured as one of the Top Branding Agencies in Charlotte. Check out their profile here.
So today is the day.
That web project that you’ve been tirelessly building for months is ready for launch. You’ve completed the checklists, aced the internal approval process and now you are ready to release it to the world and accept the accolade of your peers! All that remains, is to send an email to the development team and PRESTO, 30 minutes later your baby is LIVE! Wow – that was easy, now lunch.
Yeah, not so fast. Unfortunately, anyone who has experience launching web projects knows that this is never the case. Every launch is different and each one presents its unique challenges, requiring special preparation. Yes, there are certain steps that must happen as a part of all launches, but there are also dynamic variables impacting every scenario differently.
Having a clear launch strategy and making sure everyone involved is on the same page is vitally important. But, no matter how well you mapped your launch strategy, sometimes things just don’t go according to plan. So to help minimize these issues, we’ve collected four observations and tips that our team has successfully implemented with our launches.
Sanity Check #1: The Myth of the Magic “Go Live” Button
There will be at least one person in the chain of command that doesn’t understand the time it takes to go live with a website or app. We need to recognize that not everyone understands the intricacies of the launch process and do our best to educate them BEFORE the launch to avoid the inevitable, “why is this taking so long?”.
The best solution is to be proactive; work with your development team weeks before the launch date to create a plan of action that outlines the major steps and provides some detail of time requirements for each.
Often we find that the larger the client, the more complex their launch becomes. Large organizations frequently require coordination with internal IT teams that have established (and sometimes rigorous) protocols and security testing. In these cases, it’s important that launch plan discussions start well in advance to allow the time their IT team requires and to build it into your schedule. One of our Washington DC clients, Exostar, squarely fit in this camp, requiring several weeks of internal assessment before launch.
Once you have a plan in place, identify some milestones for check-ins with the team, and most importantly, communicate this plan to them in advance. Not only does this help keep everyone on the same page, but it also ensures no one feels like they are out of the loop. This will help keep managers and process drivers from knocking on your door while you are in the thick of things.
Sanity Check #2: It’s Just Down, It’s Not Down And Out
Even the best launch plans occasionally require downtime during the process. More frequently, product launches are updates and not brand new, which means an existing user base may be affected by possible downtime during launch.
The most straightforward approach to avoid an onslaught of customer service calls is to make users aware of potential downtimes ahead of time so that they aren’t surprised by it. Communicate these downtimes paired with the value they will be gaining from the update. It is much better to be proactive and positive, than reactive to a potentially negative situation.
Sanity Check #3: There’s A Bug! Time To Burn Down The House
Yep, you (but more often someone else) found a bug that wasn’t there during testing. Don’t sweat it, these things happen. The most important thing to remember, despite how others may be making you feel, is the launch is not a failure. More often than not, launch day bugs are due to configuration discrepancies between the development and live environments, DNS problems, or simply a cross-browser bug that may have slipped through the cracks during testing. These are common issues that developers and web hosts troubleshoot on a daily basis. Most times, these problems have a quick solution, keeping your timeline and delivery in tact.
But what if the bug is big enough to warrant a serious issue? That’s okay too. In reality, if you’ve followed a launch plan, an issue this big happens very infrequently. This is why you had a process and as part of that, built in a backup of the version of the site or app. Switching back to the previous version should be as easy as pulling up the old backup to live, while pulling the new site down to fix the issue.
So while there is no magic “go live” button, your backup is a magic “save your a**” button.
Sanity Check #4: “Can We Just Change This One Thing?”
Scope creep is real, and more so on launch day when individuals who procrastinated to provide their feedback find it most convenient to provide it. These last minute changes should be avoided at all costs, especially if you value the sanity of your development team. Even a minor change, such as switching a font color, moving a button or changing an image, can create a trickle-effect time delay to your launch. Once the site has been approved the site for launch, there should be a shared understanding that unless something is business critical, any modifications will only be made after launch.
At the end of the day, these sanity checks won’t address every issue, but rather is our tongue in cheek way of stressing the importance of coming up with a process, communicating it to your team and sticking with it. Even when everything doesn’t go according to plan, if all parties involved are on the same page about how to handle issues, you get to be the hero, and everyone loves the hero.
About the author
Ryan Johnson
Ryan Johnson is a developer working with the team at Peaktwo in Charlotte, North Carolina. On a daily basis, he interfaces with clients across multiple industries to conceptualize and build user-facing tools that push the boundaries of digital marketing. Having made the switch from design to development in 2011, Ryan prides himself on bringing a usability-first approach to every development project he works on, while still staying on the cutting edge.
In addition to guest posting on the UpCity blog, peaktwo is featured as one of the Top Branding Agencies in Charlotte. Check out their profile here.
So today is the day.
That web project that you’ve been tirelessly building for months is ready for launch. You’ve completed the checklists, aced the internal approval process and now you are ready to release it to the world and accept the accolade of your peers! All that remains, is to send an email to the development team and PRESTO, 30 minutes later your baby is LIVE! Wow – that was easy, now lunch.
Yeah, not so fast. Unfortunately, anyone who has experience launching web projects knows that this is never the case. Every launch is different and each one presents its unique challenges, requiring special preparation. Yes, there are certain steps that must happen as a part of all launches, but there are also dynamic variables impacting every scenario differently.
Having a clear launch strategy and making sure everyone involved is on the same page is vitally important. But, no matter how well you mapped your launch strategy, sometimes things just don’t go according to plan. So to help minimize these issues, we’ve collected four observations and tips that our team has successfully implemented with our launches.
Sanity Check #1: The Myth of the Magic “Go Live” Button
There will be at least one person in the chain of command that doesn’t understand the time it takes to go live with a website or app. We need to recognize that not everyone understands the intricacies of the launch process and do our best to educate them BEFORE the launch to avoid the inevitable, “why is this taking so long?”.
The best solution is to be proactive; work with your development team weeks before the launch date to create a plan of action that outlines the major steps and provides some detail of time requirements for each.
Often we find that the larger the client, the more complex their launch becomes. Large organizations frequently require coordination with internal IT teams that have established (and sometimes rigorous) protocols and security testing. In these cases, it’s important that launch plan discussions start well in advance to allow the time their IT team requires and to build it into your schedule. One of our Washington DC clients, Exostar, squarely fit in this camp, requiring several weeks of internal assessment before launch.
Once you have a plan in place, identify some milestones for check-ins with the team, and most importantly, communicate this plan to them in advance. Not only does this help keep everyone on the same page, but it also ensures no one feels like they are out of the loop. This will help keep managers and process drivers from knocking on your door while you are in the thick of things.
Sanity Check #2: It’s Just Down, It’s Not Down And Out
Even the best launch plans occasionally require downtime during the process. More frequently, product launches are updates and not brand new, which means an existing user base may be affected by possible downtime during launch.
The most straightforward approach to avoid an onslaught of customer service calls is to make users aware of potential downtimes ahead of time so that they aren’t surprised by it. Communicate these downtimes paired with the value they will be gaining from the update. It is much better to be proactive and positive, than reactive to a potentially negative situation.
Sanity Check #3: There’s A Bug! Time To Burn Down The House
Yep, you (but more often someone else) found a bug that wasn’t there during testing. Don’t sweat it, these things happen. The most important thing to remember, despite how others may be making you feel, is the launch is not a failure. More often than not, launch day bugs are due to configuration discrepancies between the development and live environments, DNS problems, or simply a cross-browser bug that may have slipped through the cracks during testing. These are common issues that developers and web hosts troubleshoot on a daily basis. Most times, these problems have a quick solution, keeping your timeline and delivery in tact.
But what if the bug is big enough to warrant a serious issue? That’s okay too. In reality, if you’ve followed a launch plan, an issue this big happens very infrequently. This is why you had a process and as part of that, built in a backup of the version of the site or app. Switching back to the previous version should be as easy as pulling up the old backup to live, while pulling the new site down to fix the issue.
So while there is no magic “go live” button, your backup is a magic “save your a**” button.
Sanity Check #4: “Can We Just Change This One Thing?”
Scope creep is real, and more so on launch day when individuals who procrastinated to provide their feedback find it most convenient to provide it. These last minute changes should be avoided at all costs, especially if you value the sanity of your development team. Even a minor change, such as switching a font color, moving a button or changing an image, can create a trickle-effect time delay to your launch. Once the site has been approved the site for launch, there should be a shared understanding that unless something is business critical, any modifications will only be made after launch.
At the end of the day, these sanity checks won’t address every issue, but rather is our tongue in cheek way of stressing the importance of coming up with a process, communicating it to your team and sticking with it. Even when everything doesn’t go according to plan, if all parties involved are on the same page about how to handle issues, you get to be the hero, and everyone loves the hero.
About the author
Ryan Johnson
Ryan Johnson is a developer working with the team at Peaktwo in Charlotte, North Carolina. On a daily basis, he interfaces with clients across multiple industries to conceptualize and build user-facing tools that push the boundaries of digital marketing. Having made the switch from design to development in 2011, Ryan prides himself on bringing a usability-first approach to every development project he works on, while still staying on the cutting edge.
