Failure to Launch

We’ve all been there. The clock is ticking down to launch and the issues keep mounting.

Some issues are launch critical, but many of them could wait until after the site has been launched. Some are new features disguised as bugs. All of them, though, will delay the launch. And no matter where you sit on the project team, not launching on a deadline that you know you can meet can be extremely frustrating—especially when those delays can last months or even years. (Yes, I said years!)

Why are delayed launches bad?

Before we explore how to avoid unnecessary launch delays, let’s explore why delaying launches can be a problem. Maybe you need some convincing...

The biggest risk is that the developers and designers will forget what they’ve done and why they’ve done it. When you’re in the midst of building a complicated website, it’s challenging to remember why you made certain decisions along the way. But if you have to revisit something two or even three weeks later (not to mention months later), you might have forgotten that a changing a piece of code will actually affect three different components—not just the one you need to update. This leads to more bugs, more testing, and more delays.

Another critical factor in launching: morale. The project team has poured their time and energy into the project and delays deny them final gratification. Especially if they’ve done something cool on the project that they want to show friends, colleagues, or even prospective clients. But they can’t because the site hasn’t launched.

Last, the project will nibble away at the project team’s time and focus. It’s hard to get into the groove on a new project when you need to spend a few hours a week updating an old project that just won’t launch! It’s the tetris problem of project management and the more of these little pieces you have lying around, the harder it is to effectively allocate resources—and the harder it is for those resources (aka people) to actually finish a task.

To delay or not to delay?

Despite all these issues, sometimes a launch delay is necessary. Maybe a feature is more complicated than you expected and the timeline needs to be adjusted. Or maybe an entire set of requirements were missed somewhere along the line—and those requirements are absolutely, 100% critical for project success. Any of these should be reasonable and limited delays as the problems outlined above still stand. The longer the delay, the bigger these issues become.

A few common problems that delay launches unnecessarily

There are many, many little problems that unnecessarily delay your launch, but there are a few that have resurfaced a time or two for us.

If you are migrating data from one database to another, a big pothole on the road to launch will be inconsistencies in source data. Do not wait until the end of the project to test the data import—even if you’ve provided explicit instructions on how to format the data. There will always be problems with inconsistent data when doing an import. Expect it, embrace it, plan for it.

Probably the most annoying thing to delay a launch: infinite nitpicking. People reviewing the site want the logo a little to the left—no, move it back. Or they want to see the homepage with a different style component for featuring content on the homepage. These nitpicks do nothing to move the project closer to launch. What’s more, actually launching can often quiet the flow of the nitpicks.

But the biggest factor in delaying launches: scope creep. There are actually a few of ways that scope creep can sneak into a project and you need to keep a steadfast eye on them. More than anything, launching on time is about managing scope.

The fastest way for scope to creep: your client talking directly with your designer or developer and making a suggestion or two. The developer thinks these are fairly simple, reasonable requests, so implement them without consulting other people on the team. One or two of these won’t kill a timeline, but 5 or 6 will as each of them adds new testing time and even creates some confusion on the team. In the worst case scenario, what the developer thought would be easy ends up being more complicated—and once you’ve promised something, it’s difficult to back out.

Another way scope creep wiggles its way into projects: New features disguised as feedback on an existing ticket. This is not always an easy thing for developers to see as it can happen so gradually—an actual bug leads to another bug leads to some re-thinking on how the feature should actually work. Maybe the new direction is better than the old, but it’s still going to delay timeline and increase costs—both of which need to be accounted for.

Get that site launched!

So how do you do it? How do you maneuver the project out of launch limbo so that it can be released to the world? It ain’t easy. But there are a few practices we’ve developed over the years that can make a big difference.

The easiest way is to prepare for launch at the outset of the project. If you wait until time to launch to set clear expectations about your launch process, then you’re going to have a bad time.

First, you want to change their mindset about what a website actually is. Many people still view websites as stagnant, immovable forces that, once launched, will never, if rarely, get updated, which is why they want everything absolutely perfect prior to launch. This mindset needs to change. The web is, and has always been, an evolutionary medium. New learning can happen quickly and what you thought was perfect at launch, may prove to be fatally flawed. Better to launch something that is good enough that can evolve based on feedback.

Second, pursue a retainer as soon as possible. Not only will having a retainer allow you to reinforce the idea that the web is an evolutionary medium, but will also give you the runway to help them evolve their ideas without having to scrounge around at the end (which can often leave clients feeling like you’re doing a bait-and-switch on them).

Lastly, if you can, add some time at the end of the project—even if you don’t tell the client—or them to nitpick and tweak features. It’s going to happen no matter how great the client is or how much you prep them, so if you can make that part of the schedule, you can avoid unnecessary delays (and maybe even launch early if they have limited nitpicks).

All these suggestions are great, but are only effective if used at the outset of the project. What happens if you get to the end of the project and you’re running into these problems?

Well, you’re S-O-L.

Not really. (But it is harder to get the client focused if you haven’t been talking about it throughout the project.)

As the clock ticks down to launch, you need to change the rules for filing bugs a bit. Add a new facet to your bugs: launch-blocker. Only bugs flagged as a launch-blocker will get fixed prior to launch. Everything else will get prioritized and resolved post launch. This will require some finesse on your part as what the client thinks is a launch-blocker and what you think is a launch-blocker may be two different things. But you want to reserve the launch-blocker flag for things that are critically broken. (Hopefully you don’t have too many of those at this point!) Everything else can be fixed after launch.

In fact, you can even work this into your process and include that in your periodic process overview discussions.

Launch!

Launching a new or updated website can be challenging, but with enough preparation and planning, you can minimize the tendency that clients have for delaying launches. Help them understand why delayed launches are bad. Recruit them as partners to help you stay on time and only delay when absolutely necessary.