How to fail well in IT Projects

Failure Is the new success. Here are five ways that you can embrace failure and enjoy its unexpected benefits.

Knowing when to say enough is enough and kill an IT Project must be among the hardest skills to learn. I’m not sure any of us ever totally master it either. When your sponsor has invested a considerable amount of money and you and your team have invested time, blood, sweat and tears it can be difficult to admit that a successful outcome may elude you.

It’s has been front of my mind of late because I’ve had to deliver this news to a couple of clients who had asked my advice on their off-course IT projects.

One, in particular, demonstrated how painful this realisation could be. The CIO asked me to look at what he described as a “runaway train” and when I arrived the team was diligently running through the failing project solution checklist … “What if we asked for more money, more time, more resources, more people, what and who could we borrow from other projects in the portfolio …?”

If you think about an actual “runaway train” what would you do? Add more fuel? Borrow drivers from other trains? Add more engines or carriages? Or would you look for a way to stop it before it did some real damage?

You need to give your IT teams the freedom to fail.

This team of consummate project professionals were, naturally, so into their own project that they were willing to sacrifice the efficiency of others in the portfolio to deliver. Of course, if your project is the most strategically important mission on the books and will deliver business goals that are key to your company then this is a good option but this wasn’t the case here. The project had one of those arbitrary deadlines that you apply because “a goal without a deadline is just a dream”, the team had glaring capability gaps and, frankly, a much better (and cheaper) solution to the business need existed in the Project Management as a Service Market.

They told me that they felt afraid to kill the project because “failure was not something that was culturally acceptable”.

Let’s think about that for a moment. If you stopped that real “runaway train” you would be a hero, you would probably get an award and a fabulous write up in the newspapers. Why don’t we do this with IT Projects? Why don’t we incentivise putting up your hand and flagging a fatal flaw?

Have you ever seen Astro Teller’s TED talk “The unexpected benefit of celebrating failure”? It’s brilliant! As head of X (formerly Google X) Teller talks about how ‘failure’ is rewarded. He says, “We work hard … to make it safe to fail. Teams kill their ideas as soon as the evidence is on the table because they’re rewarded for it. They get applause from their peers. Hugs and high fives from their manager, me in particular. They get promoted for it. We have bonused every single person on teams that ended their projects, from teams as small as two to teams of more than 30.”

I encourage you to watch the whole TED talk, it’s really interesting and inspiring. Teller shares how they consistently try to break their projects and find the ‘fatal’ flaw that will kill off an idea, he adds, “Trying to prove that we’re wrong. That’s it, that’s the secret. Run at all the hardest parts of the problem first.”

Teller says that they actually get excited and cheer, “Hey! How are we going to kill our project today?”

Now, you could argue that if you have an under-resourced project you don’t have the luxury of being able to do this – but what a culture! If you started every project with an attitude like this you may actually find that your projects fail less and that you get recognition (and not criticism) from your sponsors when you have to make the ultimate call.

When I pointed out the cheaper PMaaS alternative to the board of this client I was thanked, patted on the back and paid for delivering the news that the people on the team had been afraid to. You must give your teams the same kind of freedom that you would allow an external, independent pair of eyes like mine. I came at the project with no baggage, no parameters and no stakeholder expectations – just an instruction to deal with the runaway project. If that means killing it then you need to afford that freedom of judgement to your talent.

The thing is, in an IT Project, hitting the brakes is sometimes the best thing that you can do.

Furthermore, uncovering a huge flaw in an IT project doesn’t always mean that it’s the end of the project. Often it can actually just re-route you to a more productive path that delivers the outcome you need – or sometimes an even better one. As Teller puts it, “Enthusiastic scepticism is not the enemy of boundless optimism … It unlocks the potential in every idea”.

So what causes project teams to doubt their judgement when they find a potentially project killing problem?

In his book, ‘Originals: How Non-Conformists Move the World’, organisational Psychologist Adam Grant suggests that there are two types of doubt… “self-doubt” and “idea doubt”.

Self-doubt (“I can’t do this”) is debilitating, isn’t it? You’re frozen to the spot, you don’t act. You don’t speak up or flag when something is wrong because you are afraid of the consequences … like feeling embarrassed. This is the kind of doubt that leads project teams to sit on or cover up flaws that they find. It’s not healthy.

“Idea doubt” on the other hand is exciting and motivational. When you have “idea doubt” you challenge the status quo. You push boundaries, think outside your comfort zone, you test yourself and your peers and you hone your ‘act’ until it is perfect.

Grant has an interesting way of illustrating this with the web browser that you use. He claims that there is evidence that users of Firefox and Chrome outperform users of Internet Explorer or Safari.

Why?

It’s not because one is particularly faster than any of the others nor, actually, is it for any other technical reason. It’s how you come to be using them. Users of Safari or IE (or Edge these days) are using the default browser that came with their device. Users of the Chrome and Firefox, conversely, challenged the status quo, they looked for and downloaded an alternative that suited their needs better.

It’s an interesting hypothesis. When I did I did a straw poll of project management talent in my phone book it seems to have some solid foundation. Friends and colleagues I would expect to challenge the value of continuing a dying project all say they use a browser that was not preinstalled on their PCs, tablets and phones.

Food for thought.

Surely, for IT Projects to thrive we need to populate our teams with these types of individuals. It’s not just about prescribing what browser your talent uses, a bad project doesn’t become a good one when you download Firefox! It’s about having the type of talent who challenges the default setting and looks for better solutions … without fear of things not working out.

Here are five ways that you can embrace failure and enjoy its unexpected benefits.

1 – Get Another Pair of Eyes

Often, in the thick of an IT Project, you can’t see beyond the next task. Of course, it should be someone on the team’s responsibility to have a broader perspective, a helicopter view. Even then though, when you’ve poured your soul into a project it can be hard to spot warning signs, harder still to be the one who says it’s time to pull the plug.

I am sometimes called in to do this and because a third party independent view is less coloured by a project’s history. I can give a black and white assessment. One client said that it was like taking a beloved family pet to the vet when you know what the kindest thing to do is … but you need someone else to make the judgement call.

2 – Encourage Flaw Flagging

Too many projects fail because flaws are not flagged. Usually, it is because there is a culture that does not encourage it.

Let’s be clear a fatal flaw will kill a project whether it’s flagged or not, flagging just brings project termination forward … saving precious time, money and resources that can be deployed elsewhere more effectively.

More commonly though flaws are not fatal. Flagging means they can be assessed and acted upon.

3 – To Kill Isn’t to Fail

We do need to take a leaf out of X’s Astro Teller’s book. As painful as killing a project is, it is only a failure if lessons are not learned from it. Watch Teller’s Ted talk to hear how Google’s “moonshot factory” celebrates ‘failure’ and you will instantly feel differently.

How many vacuum cleaners got binned before James Dyson perfected his first bagless machine? Thomas Edison created a terrifying talking doll that gave people nightmares before he invented the lightbulb (at something like the thousandth attempt!), R.H. Macy (of Macy’s department stores) had a series of failed retail ventures throughout his early career.

All of these people killed projects that weren’t serving them. Are they failures?

4 – Believe in Boxless

The team behind the “runaway project” that I mentioned earlier had a philosophy of “Out Of Box Thinking” that usually served them well.

What box though? I understand the sentiment behind this piece of management speak but when you open up a project to the infinite solutions that exist you create more possibilities, including calling it a day!

The “runaway project” had a great relationship with a Project Management as a Service partner. Often, when they needed extra resources or people, they drafted them in through this partnership. It was such a regular, ongoing relationship that it had fallen within the ‘box’ so when they ‘thought out of the box’ the PMaaS partner was not one of the options considered.

It would be like, a Firefox user from Adam Grant’s hypothesis never using Safari just because it’s a default browser.

Don’t think out of the box, think as if there is no box!

5 – Have Lots of Options. Lots

The artist Prince had just 15 UK top ten singles during his life. Fifteen!

When he died it emerged that there was a cache of unreleased music that was so vast that a posthumous album could be released every year for the next century.

Prince was a musical genius! To create those fifteen top ten hits he produced 100 years of music that he didn’t consider good enough for release. Sound engineer David Rivkin said that he and Prince would create two songs a day – were all of these failures? Or were they necessary experiments that ultimately led Prince to hits like “Purple Rain”.

Prince … Astro Teller … James Dyson … Thomas Edison … they all have something in common. On the road to success, they are not afraid to fail.

AND it is with words from Thomas Edison that I leave you. “I have not failed 10,000 times — I’ve successfully found 10,000 ways that will not work.”

Happy failing!

Find out more about Project Management as a Service from Stoneseed