Stop Framing Practical Project Moves as ‘Failure’

“Failure” has become an odd buzzword in IT and it doesn’t really make much sense. You wouldn’t walk up and say to your superiors, “Hey, we’re making great failure today!” or something to that end. What’s even stranger is that practical business moves are being reconsidered and described in the context of “failure,” as if that’s a good thing. In an article for the Enterprisers Project, Mark Schwartz discusses four types of “failure” encouraged by agile in a way that removes that word from the equation:

  1. Active research
  2. Hypothesis testing
  3. Encouraging innovation
  4. Bias for action

Finding Better Phrasing Than “Failure”

Schwartz frames active research as actually testing the proposed idea or service. You can test a messaging system to see which one suits your needs the most. If you test a handful of these and one doesn’t work as well as another, that one system wasn’t a failure. You merely minimized risks by testing out the possibilities. Hypothesis testing works in a similar way. If an employee comes with a great idea, create a controlled experiment and test it out. If it doesn’t work, it did indeed fail, but it ultimately just informed you on a better course of action.

Schwartz’s third example of failure, encouraging innovation, highlights a portfolio approach:

We allow a number of ideas to move forward with small experiments that will “fail fast” if the new idea doesn’t work. The point is to encourage innovation rather than stifling it before it can take root. It is also a process based on humility: We don’t know for sure which ideas are going to work, so we allow them to prove themselves.

Rather than frame this in terms of failure, I’d call this a portfolio approach. We encourage a number of ideas with the expectation that a few of them will score, and score big.

It is, essentially, an early-stage venture capital model. The net return from the portfolio is largely positive. There is no real failure here.

The final kind of “failure” is prioritizing action. In essence, you should weigh the cost of potential failure of action taken now versus the cost of delaying action to find an optimal solution. If you can take action now and set up a “quick checkpoint” to validate it, then the risk is not as great, and it is probably worth it to just take action now.

For additional elaboration, you can view the original article here:

Austin J. Gruver

Austin is a Staff Writer for AITS. He has a background in professional writing from York College.

Related Articles

Leave a Reply

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

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.