EU

IT projects: Why you need to fail more often

Projects that fail are not necessarily a bad thing. They can end up changing attitudes to experimentation and management, and ultimately improve efficiency.

Having the courage to accept failure and move on makes you more likely to minimise your losses, Gartner says. Image: Shutterstock

Having a higher rate of IT project failures could be good for your organisation, making it more efficient more rapidly.

Businesses that experience a larger percentage of schemes that go wrong are likely to develop a culture of experimentation and should become more adept at identifying the likely success or failure of projects earlier in their life, according to analyst firm Gartner.

Project managers who take an approach that accepts failure rates of between one in five and one in three will ultimately end up making technology more responsive to business conditions.

In the present uncertain economic climate, increased risks cannot be completely mitigated and are inherent in many projects that need to be undertaken, Audrey Apfel, managing vice president at Gartner, said in a statement.

"By having the courage to accept failure and move on, you are more likely to minimise your losses, learn from your mistakes, and make the organisation more efficient, more quickly," Apfel said.

Project management failings

Current common practices in project and portfolio management are failing to meet present needs, she said.

"Continued cost pressures on most IT organisations will force IT and project and portfolio management leaders to rethink how they deal with increasing demands on an already overburdened workforce. Steady rates of project failure will lead [them] and customers to accept a certain level of failure," she said.

Changing attitudes to project management and failure will also result in an improved ability to develop business cases and planning, according to Gartner. It will lead to the introduction of mechanisms to support that new mentality.

Early warning systems, stage or phase gates, and frequent reviews by unbiased individuals will become normal practice and help organisations to pull out early from projects that are failing.

In the past, improvements to project management have focused on processes, using tools for standardisation and optimisation. This approach improves things in 80 percent of cases, but creates a false sense of security in the remaining instances, Gartner said.

Comparing costs and outcomes against plans in high-risk and complex environments leads to project failures that are late and costly.

About

Toby Wolpe is a senior reporter at TechRepublic in London. He started in technology journalism when the Apple II was state of the art.

25 comments
mcarr
mcarr

The problem in many organisations is that the accounts department burdens new projects with returning some part of the cost of past failures. The more failures, the harder it becomes to get new projects funded and the more conservative those projects must become. Failure may result in innovation in theory, but that relies on the subsequent project being given the nod. More common is the slow but unstoppable clench that results in the inability to deliver anything of much value without a ridiculously positive business case.

Imprecator
Imprecator

Let's see: in the 25+ years I've been in this business I've seen plenty of project failures. I'd say that about 75% of them are due to: a) Unreasonable Expectations, particularly regarding cost. b) Constantly shifting goals c) Irrational deadlines. As a conclusion, I must say: NO we don't need to fail more often. What we need is people on the "business" side to take get their heads off their behinds.

csudholz
csudholz

Articles like this really do demonstrate how out of touch the technology development-management community is with the real-life of business productivity. There is a big difference between learning by failure through prototype-experimentation and accepting failure of technology projects. Why do so few technology commentators understand the difference? Is it really that hard?

sysdev
sysdev

There are much better ways to learn what to do than experiencing what not to do. A failed project costs time, money and the loss of the expected target. It also causes a loss of self worth and other things with the people involved. A project failing is NEVER an acceptable way to teach people or do anything else.

TRgscratch
TRgscratch

someone used the example of Henry Ford and his V8 engine. If you are well-established, can afford (time and money) to try again and again, are not afraid of being demoted or fired, and have no competitors, then failure can be a good learning.

mongocrush
mongocrush

If you read the original article that Toby got most of his quotes from they aren’t talking about improving the entire organization they are talking about improving just the project management person or team. I don’t see anything in either article that would improve anything at the organization level. Maybe Toby wrote it that way but that I’m just not reading it right. The original article is about the Project Manager accepting that 20-28% of Exploratory projects are likely to fail and developing tools to know when to abandon those failed projects. The original article says that this rate of failure is due to limited IT resources. Here is the link to the original document http://www.gartner.com/newsroom/id/2477816

wdewey@cityofsalem.net
wdewey@cityofsalem.net

When Henry Ford wanted to build a V8 his experts said it was impossible. He told them to do it anyway. They had failure after failure, but in the end they were successful. I went to a presentation by William "Whurley" Hurley and he basically said that if you are afraid to fail then you won't ever create anything innovative. I think that this is what the author may be trying to get at, but I'm not sure. Not every organization is going to be receptive to innovative ways and not every organization should be. However if you look at the really successful organizations they usually have taken a big risk and may have even failed a few times. Google Donald Trump and bankruptcy. He has had a fair share of failures, but most people view him as wildly successful. Bill

njalla
njalla

By having 100% projects failing by the logic of the author, "making it more efficient more rapidly." In my humble opinion, we should not strive for failure but for success. However, in the process of executing projects there are times when we may have failed to identify certain risks or failed to address a particular issue in a timely manner and may lead to failure of the project. I do understand that once a project has failed, it is imperative that lessons should be learned and in the future failures should be prevented (this may be called embracing the failure). To that extent I agree the failures should not be shoved under the rug but analyzed thoroughly so that in future mistakes are not repeated.

Rinnietintin
Rinnietintin

It's like saying, here's a million dollars for a COTS solution. Please implement it, and don't worry about project failure, we have failure accommodated in the project life cycle. We are just going to select another vendor if this one fails. For some reason nobody is talking about costs here. Its costs money to select a systems integrator and have them implement a solution. Companies budget for it in their budgeting plans, and they do not budget for failure. Most companies accommodate for scope creep, but that's about it for schedules that are going haywire. I don't think companies would accommodate for total Project Management failure at multiple iterations during the life cycle of the project.

jeremyoakey
jeremyoakey

Wow! The premise for this article is so poor I don't even know where to start. We are IT Professionals so planning to fail or trying to fail more to learn from the experience is a practice that will do more harm than it will ever do good. If I take my car to a mechanic for some work (a project) I expect him to do what was agreed with a high level of proficiency and not fail. I want R&D for cars to continue and improve everything but not on my car. This is just like IT projects. Many organizations don't have the time or money to work through failed IT projects and this is a problem that is already plaguing organizations so how could any sensible professional actually support failing more? There are several hidden good points here about realizing that failures can happen, preparing for them, learning from them and improving but more projects do not "need" to fail. There are other organizations that have R&D capability and can do some of the experimenting for everyone else. IT has been struggling to get a better seat at the "big boy" table and prove it can provide real business value but thanks for trying to undermine that with this foolish idea.

jobert1970
jobert1970

I do not agree with the author. All it requires to get the job done right is putting the right person to lead the project, proper planning, team collaboration and communication. His phase gate suggestion is correct, but if you put the right person from the start, then this phase approach will be done right the first time. IT failure is costly and will result to cancellation of other projects by Management, specially during this recession.

Dave Keays
Dave Keays

Failure in the IT industry comes in many different shades. Escaping all kinds of failure with absolute perfection is rare. Where is the projects weakest link? All projects designed and built by humans have them and ignoring their existence is irresponsible at best. Do you aim your design and programming to accept the failure that has the least impact on the high priorities of the project? Or should your design and programming accept the one that is most likely to go unnoticed? Do you ever wonder if a project was designed to accept failures that will go unnoticed until someone else is in place to take the blame? It seems that the priorities in medium sized businesses is usually on speed of implementation according to the specs on paper today. I think it is even worse in a large or even a Fortune 500 corp., but my experience lies elsewhere so I'm only guessing. If it is a real-life situation the most likely scenario is either the project will fail that narrow definition (web-site is up-and-running by tomorrow) or it will cause a bigger failure with a wider scope (ecommerce credentials are leaked). According to a casual look through papers about security breaches, a common example is when input for a server-side script is coming in from a source that most likely will be sanitized and it is safe to be included au natural in an SQL statement. But there is one possibility that isn't obvious where raw user input comes in. The unlikely possibility is ignored but one day it is discovered and an SQL injection that could reveal sensitive information from other departments is on many malicious hacker sites. The biggest sin in IT today is to take the time to stop and think. Why isn't it accepted as a cost of IT like the time it takes to to stop and repair? God help you if you even consider measuring twice- IT needs to learn a lesson from the building construction industry. Ignoring possible failure is like not having a backup system or AV in place. It is good for your ego if you never need it. Not only are you opening your project up to bigger problems, but you are learning less from this project by not getting ready for and handling likely future outcomes this time. If you did learn this time, you would catch the weakness earlier next time. But now you have left yourself unprepared even though your experience looks good on paper and linkedin.com.

Tony Hopkinson
Tony Hopkinson

The problem has never been realising that the wheels are coming off, or quite often have disappeared over the horizon, it's denying that the implementation won't do the job, that the requirement is wrong, that the expectation is incorrect, and agreeing that a mistake has been made and hitting the brakes or the reset button. Lots of egos in knots, reputations at risk, control in disarray and you go into either rescue mode, or redefine the success criteria. No point in waffling at IT people about this, need to start with the business people, 20 to 33% failure rate is something they do not consider acceptable. It would be nice if your next employer could benefit from the "learning opportunity", but in general corporate culture is the same world wide, mistakes are something you cover up, or pin on someone else.

JLivengood
JLivengood

I understand the concept the author is trying to communicate, however I do not disagree with the approach. Failure at the Project or Portfolio level cannot and should not be embraced. There are many IT Projects where failure is not an option, i.e. relocating a DC or a tech refresh. The issue I think that is of focus in the article is "How does a Project Manager embrace and manage innovation in the typical Project Life Cycle?" This is a challenge many organizations face and struggle with. The key here, in my opinion, is how does the Project Life Cycle support multiple iterations of failure before succeeding and how do we, when it comes to innovation, embrace a "Good Enough" mentality? These are the challenges my organization is faced with today and I am tasked to address over the coming year. It starts with the Charter of the project, IT needs to move away from a technology driven Charter and focus on a Service Delivery Charter. For example, don't create a project where the Charter is to Deploy MS Lync for example, but have the Charter focused on Delivering an IM Solution which supports Desktop to Desktop video and voice. As technologists we sometimes get lost in the technology and forget about the service we are trying to deliver to our customers, the end users. Now that the Project Charter is focused on the service, how do we manage the Project Lifecycle to allow the technical team to "fail faster before succeeding". Or to think of it a different way, how do we allow them to "successfully discover the multiple ways it won't work until they discover the way it will work". Maybe MS Lync doesn't fit the needs, maybe the Cisco solution doesn't either, but this won't be discovered until it is tried. So the PLC needs to be flexible enough to support failing faster in order to be successful. I am sorry, I will never embrace failing at the Project Level, it just doesn't seem logical to me. But I do understand, especially when it comes to innovation, everyone is going to fail multiple times before succeeding and you must embrace a "good enough" approach or the creative process will go on forever. The challenge, in my mind, is how do we build that into the our Project Methodologies?

christopher_d_roberts
christopher_d_roberts

My speciality is project recovery and the primary reason why projects fail is a lack of understanding and execution of the scope. There is no excuse for project failure and to say that it can be beneficial goes beyond stupidity.

jhorton
jhorton

Let's think about this logically for just a second - if you already have overburdened staff and budgets stretched to the limit, how can it possibly make sense to accept a project failure rate of 20-33%? You would waste precious time and resources to improve your project processes? Perhaps this would work in an alternate universe, but here in what I fondly call reality, this is deadly paradigm, for IT or any other processes. The only thing that following this tripe could possibly accomplish is the outsourcing of your IT department.

CoffeeKerri
CoffeeKerri

"Having a higher rate of IT project failures could be good for your organisation" Hmmm...given that there is already a high rate of IT project failures, this seems downright silly. While improvements can be made *if* an investigation as to why a project failed is conducted openly with all factors accounted, then it may provide valuable insight for areas of improvement. However, this is far from the norm and typically when projects fail, there is a push to hand off blame to a person or group rather than actually reviewing the project management process. Improvements on smaller IT projects can lay the groundwork applying similar principles to larger IT projects to become successful.

the-dream
the-dream

I recently left a company that is involved in a multifaceted project that is facing all three of the issues you mentioned. For Instance: The project became more expensive than anticipated and to cut cost the first thing to go were some of the expert consultants. So they rolled the dice by putting the burden on novices to implement new software packages. The project mastermind held to the statement that the project would finish "On time and under budget" and a number of decisions made in an attempt to fulfill that promise ultimately led to further delays. Many key people resigned. (Including me) because of a,b and c. That project has to be completed because many have staked their reputation on it and they have gone too far to turn back. But it wont be pretty.

njalla
njalla

I agree that failure in itself may not be bad as it can lead to innovation or improvement in processes but to suggest that one in three or five projects should fail is absurd. Nirmal

Tony Hopkinson
Tony Hopkinson

a lack of innovation. And it is a valid point, however the pelthora of WTF? responses would indicate, if that was the OPs point, they totally failed to get it across. Even then, part of taking a risk is to understand it and manage it. As well as taking the risk, you near a clear set of boundary conditions, that mean teh plug needs pulling and at best a re-evaluation is required.

Tony Hopkinson
Tony Hopkinson

You try Plan A, it dies horribly, you shrug and got to plan B, then maybe C versus You try Plan A, and then go into Norman Bates mode, pretend it's alive and sack anyone who says different. Option two despite it's obvious absurdity keeps getting chosen, not because we don't fail, but because without our mummies we dare not even admit it...

njalla
njalla

I feel all successful projects have taken risks - some of them may have been realized and many may not have realized. At the end of a project, if you examine the risk register, you will notice realized and unrealized risks. You may also notice some issues that were the result of some unidentified risk being realized. A successful project will have a number of unrealized risks. In either case, it does not make sense to fail.

Tony Hopkinson
Tony Hopkinson

of thinking is trying to promote. It's aimed at those so risk averse, they never take any and end up risking everything... Talking risky projects (new tech, new processes, new business model) not taking more risks on a project.