In this article, part of my series explaining better ROI from software development, I’d like to look at the Failure.
When I started on this article, I had planned to use it to extol the virtues of providing a safe environment for testing theories – theories that could fail – and the value behind allowing this.
During the process of writing this article I've thought more and more about failure as a Software Development ROI driver. So much of the costs of the Software Development is effected by failure – either actual or steps to avoid.
It’s easy to explain how a failed project affects costs.
It’s fairly easy to explain how a failure can provide value in its own right as part of experimentation.
What is more hidden is the cost resulting from fear of failure.
We are taught at an early age that failure is bad. Be that through school exams, childhood sports, etc. We are pretty much programmed to desire success – and anything that is not success is negative.
As we grow up, we realise the world isn't quite like that. We start to realise that lack of success is part of the journey rather than the end destination.
But we still have that fear of failure – and for me that is a really key cost to look at within Software Development.
Lets look at individual & organisational fears separately.
Think of the anxiety that comes with fear of failing.
This is one with which I can associate with. Personally I find stress quite beneficial – but when that becomes anxiety, I know that has an effect on how well I can perform.
That anxiety takes up cognitive resource – my mind works overtime on the underlying concern – this leaves less cognitive resource to actually work on the problem (see my article on the Zeigarnik effect).
While I have developed coping strategies over the years, it will have an effect on personal productivity. And I think this is true of anyone that really cares about the work they do.
Within an organisation, that fear becomes process and controls.
We fear that our project may not be on time or to cost or to quality so we start wrapping process and control round it.
But how many of them are addressing the risk of failure and how many of them are addressing the fear?
We see it quite often if a team are perceived to be failing for some reason. The immediate action is to put additional reporting or controls in place. This is intended to provide transparency and (hopefully) alleviate any perceived problem. In reality you've probably just increased the workload of a struggling team – you've actually created a death spiral which, if left unchecked, will result in the team getting worse and worse as it struggles to cope with the additional demands.
And in a lot of cases we are providing all this stuff because we imagine someone higher up the chain needs it.
That isn't to say that failure can be left unchecked – far from it. But the Organisation culture and processes need to be assessed to ensure that the correct balance is met.
Let’s take a step back and acknowledge that there are different types of failure. Some failures are the path to mastery, they are how we learn.
Take a couple of minutes and Google for quotes on failure. Most will have a common theme that failure is a step to success.
The importance in that step is learning from it.
If you continue to repeat the same failure then there is something wrong and it needs to be addressed.
The scale of the failure is also a factor. The more you risk on the failure the more likely it can become an extinction event.
Ok, so where do you draw the line.
Short answer … it depends.
As with most things in life there isn't one size fits all.
I've already talked about Agile Software Development in my articles; within which there is already a lot of advice:
I was once asked by my manager to do the easy bits first. Do the low handing fruit.
He was looking for something to show quickly. Something to demonstrate progress.
And I can see that as being valuable with Stakeholder management.
However it is the wrong way to do it from an ROI perspective.
It’s no good producing a nice looking website if its core value is impossible to technically deliver.
What would you prefer?
1 month effort wasted after a concerted effort to produce the impossible technical functionality,
Or
6 months effort wasted after 5 months of “easy but showey” work & 1 month on the impossible functionality.
The end result is the same – just one costs a lot more to get there.
You want your team confident enough to approach the complex stuff first AND be prepared to present failure.
Way too many projects have spiralled out of control with no one wanting to admit failure until such point that the money runs out.
Ok, so there are a lot of ROI benefits from embracing failure here: