How to fail well in IT Projects

Must read

IT Project Teams are STILL driving competitive advantage

IT Projects are perfectly placed to shape the future of business as we emerge from this pandemic Businesses need to be leaner and more innovative. It’s time for IT Project teams to say, “Hold our coffee, watch us do our thing” – this is our moment.

Embrace the change: Getting to grips with new IT systems

New IT systems for a growing business can be an exciting prospect and deliver many benefits, but how do you convince employees to embrace...

5 Skills Needed To Drive Future Projects

Why do projects fail? It's a question that invites a lot of interest and significant statistics. And there are no wrong answers here. Skills shortages...

Does a Project Manager Need PM Qualifications?

What makes a successful project manager is a combination of their academic abilities, experience and skills, both "soft" and "hard" skills i.e. communication skills...
David Cotgreave
If you like David's blogs - he is now a published author - Straight Talk on Project Management (VOLUME III)- Free eBook. Why not download your copy today. David Cotgreave MBA, BSc (hons), PRINCE II, is Professional Services Director at Stoneseed, with over 20 years’ experience in IT Consulting. David has worked with organisations such as BT Engage IT and KPMG, before founding Stoneseed in 2009 and has gained considerable business experience whilst working with a wide range of organisations across the UK and Europe carrying out a range of strategy, review and implementation projects. David is currently responsible for leading the Programme and Project Management services offered by Stoneseed. Project Management as a Service (PMaaS) from Stoneseed offers clients access to Project Management staff, resources and tools at a flexible and predictable cost via a fully Structured Managed Service.

IT Project Management
IT Project Managerment

Previously published on 

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.


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

- Advertisement -

More articles


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.

- Advertisement -

Latest article

Training project teams on global projects

An exciting new project has started involving teams from right across the globe – both within the organisation and from external suppliers....

Project Management Lessons learnt from Covid Holiday Disruption

The very definition of Holiday (Noun - an extended period of leisure and recreation, especially one spent away from home or in travelling), is an entirely flexible parameter to work within, so how do we adapt? And what Project Management lessons are to be learnt from this summer?

Project management for the ‘new normal’

We live in strange times. Who would have thought last year that 2020 would be the year of Covid-19, the year of...

Long-Term Strategies To Help Manage Your Team Remotely

The world has changed profoundly since COVID-19. No one saw a global pandemic coming but now isn’t the time to panic. Instead,...

10 Steps for Planning and Implementing a Successful Branding Project

Your brand is perhaps your most valuable asset. It defines your organisation’s reputation and visibility in the market. The strength of your...