In favour of failure

The idea of having full control over the results of a project is a common desire, but impossible to achieve if you are not able to control as many context and environmental conditions as possible

We know this because there is plenty of evidence reported by business professionals with experience starting projects and then having to pare back the original intent, stretching out timelines, or abandoning the project altogether. 

This is also one of the reasons why part of p[roject initiatives, we choose to create essential project artifacts like project plans and risk registers, and the like.

It is clear, that when the environment is volatile and changeable, the ability to assess new settings and adjust quickly is critical for success, perhaps even survival. An essential part of all this must invariably include the ability to accept that a bad decision will be made and there need to be strategies to recover and remediate as quickly as possible, if not immediately.

This is as true for simply driving a car to take a run around the block or engaging in those complex digital transformation and technology projects. By their very nature, projects, are subject to rapidly changing conditions. In fact, often projects are triggered by the very fact that the environment is evolving and some initiative is necessary for the organization to remain relevant and competitive or appropriate.

The Agile interpretation of this is that “failures, are not to be dreaded”. The approach, then, is summarized in the concept of ‘fail fast, fail forward’ – something that has become a bit f a common mantra in the start-up scene too.

In an Agile setting, failure comes quickly after a particular or new approach is being followed. This is by design: the notion is that investment made in a new idea does not need to be as big as in a traditional waterfall model.

By their very nature, significant waterfall projects will often involve large numbers of people who could be working on a new concept for weeks or months before an opportunity is presented for it to be evaluated, presented, or unveiled. By the time the project is revealed, it may be rejected, or worse, deemed to be a failure because the environment or the organization has moved on from it as appropriate and important.

In a two-week development, evaluation, design, or brainstorming “sprint”, you are able to observe, reflect, redo or wholly pivot. You can reset principles, assumptions, and prototypes. This approach helps one to detect issues quickly and thus the impact of failures is not big. You’re at least able to recover from a past decision with the lowest impact felt.

This also translates well to you as an individual and your general life philosophy. Committing to elaborate and lofty career and personal goals is generally recognized as important. Equally, it is important to recognize that sometimes perseverance is not enough and that what is needed is a change of plans.

Being comfortable and safe will almost never drive us to excellence. In order to achieve great things, we have to bring everything together. If we’re not taking some sort of risk then perhaps we’re not pushing hard enough.

Failure is only really a failure if it is final. If you don’t learn from it and give up then it is final. If you continue to persevere missteps and failures along the way, then you have to recognize that it is part of the process of getting better.

As long we keep learning from our mistakes and possible failures, we should recognize that this is not necessarily failing it is just a part of the process of learning.

Published by

Uli Lokshin

Content contributor and thought leader around SAP, data management and data management practice and digital as well as topics that are of interest to me that relate to organizational and business social dynamics, leadership, and employment. Feel free to connect with me on https://www.linkedin.com/in/ulilokshin/

Leave a Reply

Your email address will not be published. Required fields are marked *