The term ‘fail fast’ always makes me cringe a bit. It sounds so negative. For most people, it is all about stopping things in their tracks, and not necessarily finding workarounds or solutions to problems.

I’m not alone in my dislike of this term, either. Jeffrey Hayzlett, the author of Think Big Act Bigger, is clear that you should never plan for business failure. He refuses to accept that there is any such thing as a ‘no win’ situation, and complains that failure has become something of a ‘badge of honour’. Yes, of course, anyone can fail, and it is important to get up and try again. But we don’t talk about the people who have continued to fail. You have to succeed eventually to be celebrated. Heroic and ongoing failure is not a good option.

There’s more. In his ‘Mythology of Fail fast’, Ved Sen asks “How many projects actually spend time defining failure, and if not, how would you know when you’ve failed? And what happens then? Is there clarity about the next steps? Of course, recognising failure requires that projects are instrumented, or that the data gathering is built into the prototypes or pilots. In fact, Eric Ries defines a start up as a learning machine. The reality is, most new projects aren't.” Ultimately, we all want success. Perhaps we need to change the conversation.

Learning quickly instead of failing fast

With the Internet of Things and Digitalisation changing and disrupting markets with an unprecedented pace, most companies feel the urge for quick and successful change. We can probably all agree that an organisation is likely to be more successful if its employees learn quicker, and implement and commercialise knowledge faster than the competition. Simply failing is actually neither fun nor any guarantee for future success.

So how can we make sure this happens? Each time we try something new, we need to extract the lessons. What went wrong? And what went right? Why? What new things do we now know? How can this knowledge be used more effectively by us than by anyone else?

Of course people need “permission to fail”. But this must be accompanied by the capacity to see what has happened, learn from it, and then shape alternatives. The essential skill to enable this is critical thinking. To my mind, this includes:

• Root cause analysis. Why did something fail? It is important to dig down beyond the superficial reason (for example, not enough money) to the ‘root cause’. And here’s the crucial aspect of this: when you think you’ve found the root cause, you probably haven’t. It’s worth digging deeper again. Keep asking ‘but why?’ until you are satisfied you have found the real cause, not just the symptoms.
• Integration and synergy. It is easy to test simple things. It’s much harder to deal with the complexity that comes from a wide range of stakeholders, broader capabilities and more moving parts. But it is important to try to do so, and particularly to think about how you can manage the challenges of doing so. It is also critical to explore if you can combine two or more things to do more than either in isolation.
• Circumvention. Sometimes it may not be possible to tackle a problem head-on. Instead, you may need to find a way around it. Continually beating your head against a brick wall as a way of knocking it down is generally agreed to be less productive than finding a ladder.

This ‘critical thinking’ shifts the perspective towards insightful learning. It helps teams to develop genuinely thoughtful responses to a problem. But it will often demand more than simple mind-set changes from a team. At least as important is to establish a supporting technological environment. We live in project driven work cultures - where the actual "setting-it-up", "getting-to-work", and "what's happening after?" phases eat-up most of the total project time. Often months which companies simply won't have anymore in a digitised world.

How companies have gained from #bigdatalab

A Big Data Lab, respectively an IoT Analytics Lab, creates the necessary environment designed for experimentation. This sets the right expectation, both for ‘failure’ and for the necessary learning from it. We have now been working with customers for a year on their big data labs, and the results have far exceeded expectations. As Andreas Goedde indicated “Innovation requires experimentation. Experimentation requires enthusiasm. Enthusiasm is driven by speed, teamwork and fast results.” And the Lab provides even more than enabling teams to constantly experiment with data. It ensures that models are based on realistic data scenarios and provides a structured way to hand over and deploy models quickly.

Learning fast leads to success. With failing fast, there is no such guarantee. As IoT becomes more mainstream, and organisations have more need to test and trial ideas, we suggest that organisational learning needs to be faster. To have a deeper understanding of what IoT early adopters have done, read the e-book Internet of Things: Visualise the Impact.