Failure is not an option!
I’ve heard that phrase a number of times during my career. Mostly by people imitating a manager they heard in a meeting, but still too often.
What’s remarkable is that this phrase is usually uttered at the moment that it is becoming very clear that, yes, failure seems to not just be an option, but fairly likely!
And that’s the thing. Failure is always an option. The question is, what are you going to do about it?
Failure is always an option
No, let’s step back from that for a minute. First let’s see what we mean by failure. For many project managers, a project is a failure if it’s not delivered on time, and with the complete scope that was agreed. I’ve hurt project manager’s feeling at times by reminding them that according to their own definition, budget was also part of that equation.
A project for which people have had to work overtime, was a failure
Overtime means that you found out there was a problem very late, and at that point did not have a good enough relation with your customer to be able to negotiate release date or scope. That’s a good description of project management failure. Which is not to say that the project manager is the only one that failed, btw. That sort of thing requires a team effort…
Back to the options for failure.
Failure should not just be an option, it’s a requirement. If you go through a whole week of work on your project, and there’s no failures at all, it’s time to get worried. Because either you’re not noticing the failures, or you’re simply not trying hard enough.
You should have found some things that were harder to do than expected. When you do them again, later in the project, they’ll be easier, if you noticed this failure and learn from it. You should notice that your velocity over the last three sprints has been lower (or higher!) than expected. You need to adjust your planning accordingly, and talk to the customer about possible scope or release dates changes. Your continuous build broke five times in the last sprint. You should be talking in the team why that is, and ensure it doesn’t happen again. Your newly written unit test fails. Of course it does, you’re working test driven! Your customer keeps adding to and changing requirements during the sprint. You should make the requirements more explicit before the sprint starts, so that it’s clear the requirements are new.
Failure means learning. Failure to learn could mean… lack of success.
The more you allow failure. The more you encourage failure. The better you will be at detecting failure. The lower the threshold be for your people to report failure. And all that will help you navigate towards success.
Success consists of going from failure to failure without loss of enthusiasm.
— Winston Churchill