Failure is not an option … it’s a necessity

•

Lots of IT projects are said to fail – many people are complaining, calling shame on the IT profession. An example is the recent article Okay to fail from the CIO Weblog, which talks about poorly run projects and underperformance.

Most IT projects are not in a predictable context, but in the complex domain – as I’ve argued before. In the complex domain, failures are a necessary part of the learning process, part of the way you make sense of what’s happening. IT projects are not in the domain of ‘best practices’, you don’t have complete (mental) models of how projects work, you can’t predict them.

A more sensible strategy is to probe, sense, respond (or apply, inspect, adapt in agile terms) – i.e. try something, look what happens, and base your actions on this information. What does trying something mean? Raymond Salzwedel describes it in 9 principles of safe-fail probes:

In the complex world (…), we rather need to create ways that allow unpredictable things to happen, and then to have a plan to deal with them, and learn from them. Moreover, we can even create situations that will test the stability (or lack thereof) of a complex system, and then observe the results. If it goes wrong, that is OK – it is allowed to. We can call these types of interventions or events, Safe-Fail.

So, failure is good, failure is a necessity. It’s a means to a higher end. Please stop complaining and whining about failing IT projects; stop calling IT such a bad boy; stop burning the guilty at the stakes – that doesn’t change a thing, it only creates fear and prevents any learning from happening. Leave out judgment and take what’s currently happening as information. Use failures as probes in the complex space of IT and learn from them.

Not only accept failures, also plan for failures as part of portfolio management: take into account that a part of your portfolio will not deliver what you want. That’s ok, it’s part of the organizational learning process.

Some tips on what to do when a project goes awry:

  • Don’t panic! What’s happened, has happened; postpone judgment, regard the failure as information, run a retrospective to learn from it.
  • Allow peope to fail in your organization. In particular, check your reward system – it probably rewards success and punishes failure. Your organization will learn most from its failures however (this is not an easy change…)
  • Make sure the people involved get a soft landing and an opportunity to recover – failure is necessary for learning, but being part of a failing project can be ugly and stressful, provoking strong emotions.
  • Work in an agile way to help you fail early and often. Working in an agile way helps address risks and uncertainties early on. You can detect wrong assumptions and other problems in a matter of weeks instead of months or years; this saves a lot of financial and emotional investment. Furthermore, it enables you to run a lot of small projects as experiments.
  • Set up projects as safe-fail probes: small and incremental; make sure that if they fail, you can afford it and you will learn something.
  • If you want to label a project as a failure, investigate why. When is something a failure? Donald Gause and Gerald Weinberg define a problem as a difference between what you perceive and what you desire. A failure then means that you tried to make the difference smaller, but it is still there (or it’s even bigger). Investigate the project from the viewpoint of your desires and perceptions, how these changed over time, and how the project has affected both.

References

Do you want to get more out of your failures? Would you like to learn how to use safe-fail probes to get more out of your IT? Feel free to contact us.