November 21, 2014

With almost every aggressively-timed project launch, the race to the finish line can easily become a game of task resolution whack-a-mole. With anxieties running high, the pre-launch to-do list can easily balloon to an unmanageable size. New requests come streaming in seemingly as fast as (or even faster than) previous requests get checked off.

To keep the launch plan on track, every project should maintain a list of launch blockers. But what exactly makes something a launch blocker?

What it is

A launch blocker is any outstanding item that makes a late launch a better outcome than a launch lacking that item.

The qualifying characteristics of launch blockers will vary for every client and every project. This requires analysis. It can be hard to obtain the necessary data to determine the impact of a late launch versus a scaled-back launch. You may need to do some hand-waving. The value may not be only made up of hard metrics; there could be unobservable impacts. Often a client may have to assess the impacts on their own, based on their knowledge of organizational needs and priorities.

What it means

Due to high anxieties, launch blockers often are submitted at the eleventh hour. This feels unfair to the issue solver, as the time remaining before a launch is often insufficient to resolve the blocker. On the flip side, it feels unfair to the issue submitter to have the launch affected by the time to fix because this leaves the entire launch at the solver’s mercy.

Yet, the very nature of a launch blocker is that it halts a launch until it is resolved. The sum of all launch blockers’ time to resolution will always set the launch time and date.

So, when submitters declare an issue a launch blocker, submitters are really agreeing that “this issue is more important than our launch, and the launch date will be determined by the launch blocker’s solver.” This fact alone will discourage issue submitters from exaggerating the level of importance of an issue, because this declaration means issue submitters must hand over control to the issue solvers.

What you can do

Non-solvers are not totally disempowered. In fact, non-solvers can make an enormous impact on the timeliness of a launch blocker’s resolution by doing a few simple things:

  • Clear the path. Find ways to put any other projects or distractions on the back burner. Make sure everyone knows that the solver needs to focus on the launch blocker and nothing else.
  • Set the stage. Non-solvers can work to get the solver everything they need to complete the task at hand. Give specific details about what is not working, when and where it is not working, and how it should work.
  • Check in regularly (but don’t over do it). Sometimes people don’t recognize they’re spinning their wheels until they break their focus. Be careful not to interrupt too often such that efficiency decreases.
  • Be available. In case the solver raises their hand, you want to make sure they get what they need right away.
  • Be a cheerleader. Resolving launch blockers is one of the most stressful parts of a solver’s job. Keep calm, be appreciative, and know that they are working as best they can.

Remember that the project team is all working toward the same goal. Whether you’re all at one organization or spread across a dozen, work together to get the project launched. And once it does (no matter how gruelling or painful), take time to thank every person for the hard work they contributed, regardless of the role they played in the project. Then take a deep breath, and bring on the next project.