Showstoppers

On a project, you can come across risks that, if they happened, would be complete showstoppers, stopping the project dead in its tracks. They will force you to either rethink the project or give it up. It is important to identify showstoppers as they call for entirely different handling. You can only handle them in two ways:

  1. Put them in project assumptions (you assume they won’t happen)
  2. Dump them at the feet of the client or project sponsor (as they are miles outside of your control)

It is really important to get the project sponsor to realise these are his to deal with, as they are beyond the responsibility of the project. So what do showstoppers look like? Examples include:

  • Product build is based on an OS that the supplier upgrades to an incompatible version (this has happened to me when SAP completely changed the architecture of their CRM solution)
  • Client’s company gets taken over or hits economic problems (had this one too)
  • Software built on top of a client’s system that falls out of support (pretty common with desktops not being capable of upgrade)
  • Mass resignations by team members due to pay dispute (has happened with offshore teams where rival offered more money)

You might be inclined to ignore showstoppers. If you can’t do anything about them, why bother? Remember, these are too big for you to control, so pass them up the chain of command. The project sponsor has to deal with project assumptions turning out false (and you can even put in the assumption that they will deal with them). Ignoring them doesn’t make them go away. If a risk doesn’t happen and you ignored it, doesn’t mean it couldn’t have bitten you. If you sail in a dodgy boat and get across the channel, it doesn’t mean you couldn’t have sunk. You were just lucky. Deal with every risk and make sure every risk has an owner.