Episode 003: Project Failure

Play Now:

In today's show we are talking about project failure. We'll look at the numbers of failing projects quoted in various statistics and the critical success factors identified in order to have a successful project. But most importantly, we want to know how project managers who are faced with a failure manage and cope with this failure.

Episode Transcript

Below are the first few pages of a computer-generated transcript with all its computer-generated quirks.

Cornelius Fichtner (00:11):

You are listening to the project management podcast. We bring project management topics to beginners and experts. Find us on the web at PM. podcast.blogspot.com or send your emails to PM This email address is being protected from spambots. You need JavaScript enabled to view it.. Hello, and welcome to the third show. This show was recorded on the 17th of September, 2005 in it. We'll talk about project failure, and I know I have to go and get some Kleenex because I'm sure I'll start crying. And just a minute, in my last show, I said that this show was going to be the second part of my review of the 2005 PMI leadership meeting in Toronto, Canada. But due to current events, I have changed the topic for today and we will talk about project failure in my resume. I sometimes mentioned that I have successfully implemented all assigned projects over the past five years. Of course I was lying when I said that, because in truth, I had successfully completed all projects over the complete 15 year project management career.

Cornelius Fichtner (01:26):

But since nobody would believe that I cut it down to five years, I don't really know why I have been this successful. My best guess is that it's probably a combination of just plain good luck, a certain talent for project management and simply being assigned the right projects, those projects that weren't meant to fail, but now it looks like I'll have to delete that sentence from my resume because one of my projects is failing and probably has failed. Let me give you the background of this. I work in the it department of a bank. Well financial institution, really. We are roughly 130 people of which half are software developers. We support about 120 applications. We have a very quick turnaround for a financial institution. We have a software release every month, and of course there's a hell of a lot of risk involved with this quick turnaround.

Cornelius Fichtner (02:28):

When you just push out software, every 30 days testing on the other hand to mitigate this risk is quite minimal people test the new features. People make sure that well it's now no longer green. We've changed it to blue. They make a quick test. Is it blue? Yes, it's blue. Perfect. Let's move on. I got real work to do here. I don't need to test this software. There are really no regression tests in all of this. I doing the project that has now failed. We were hoping to establish some sort of a suite of system tests that we could run during the release weekend. Until today, we've been able to set up to create a basic environment test. Uh, we were able to create a suite of smoke tests and we have about 75 manual user acceptance test scripts that really tests just the availability of the most critical functions in the applications.

Cornelius Fichtner (03:33):

So these 75 tests, we went to the users and said, Hey, if you show up on Monday morning and you needed to work with the system, what's the most critical stuff that you need functioning. So we have that that's available, that's here and ready. And it took about a year to create all this my original plan. However said that at this point in the project, we should have a finished and automated suite of all of the tests that I mentioned and much more as of yesterday, I have decided that this project has failed and it stuck with absolutely nowhere to go. Trust me, I was absolutely pissed about the fact that I had failed. I was grouchy. I was bad tempered. And just generally in a sour mood about this, I needed a shrink to get me through this, some sort of a psychologist. So I went to doctor Google and I searched around.

Cornelius Fichtner (04:36):

And in the end of all, places, I ended up on the pages of alcoholics anonymous, where I found their original 12 step program. And then, you know, the 12 step program, it's nothing more than a methodology, right? So what does a good project manager do? He reads the methodology and then he decides which parts he wants to take and which parts he wants to leave. And frankly, for me, only the first two step, really, they, they helped, ah, here they are. First step. We admitted that we were powerless over alcohol, that our lives had become unmanageable. Second step, we came to believe that a power greater than ourselves could restore us to sanity. Okay. Yeah. The first one, absolutely. I admitted that I was powerless over the failure of this project and I admitted that the project had just become unmanageable, that it was going nowhere.

Cornelius Fichtner (05:37):

And I also came to believe, step number two, that a power greater than myself. Um, let's see executives, the sponsor or business users that only they could restore this project back to its sanity. Hmm. So that helped me get over mine, just complete frustration of having to face my first failed project, my failure. However, it got me thinking and I wanted to know, is it really true that 70% of all it projects fail because with my track record, it's statistically wrong. So back to Google start surfing around. One of the things that I found is probably the most widely quoted statistic on project failure. It is the Standish group's chaos report. They've been doing that since 1994 and they have analyzed thousands of projects and they have come up with three categories on how projects succeed or fail. First category is of course, a successful project, meaning that the project is completed on time and on budget with all features and functions as originally specified.

Cornelius Fichtner (07:05):

Then there are the challenged projects, the project is completed and operational, but over budget late and with fewer features and functions than initially specified at third. Yep. That's the failed project. The project is canceled before completion or never even implemented so much for these three categories. And when you look through the Standish reports over the years, the chaos reports, what you'll see is good news folks. What Standish saw was a massive increase in projects that were executed. And at the same time, the percentage of successful projects has increased a lot more than the percentage of those projects that have failed based on these three categories that they've had. And a lot of thank you goes of course, to project management and the according processes behind it. So project management really, really helps to make a project successful. Yeah, we all knew that, right. But what are the critical success factors for these projects? Well, the chaos report, the original Carol's report talked about the chaos 10, the 10 critical success factors to make a project succeed. And when I looked at those, I had my big

Cornelius Fichtner (08:41): Oh

Cornelius Fichtner (08:42): Experience, which really, really explained why my project is failing, what's failing. And all I had to do was look at the first four of these 10, what they did is they also graded them and they gave them a number. And the first four, they add up to 60% of why projects fail or succeed. And here are the first four executive support, 18% user involvement, 16% experienced project manager, 14% and clear business objectives. 12%, no wonder my project is failing. I have no real executive support, 18% right. Gone. The user involvement is absolutely minimal. They don't give at dingoes kidneys about testing. They have real work to do and clear business objectives. Yeah, not really. Okay. So 46% of my critical success factors right there gone experienced project manager. Yeah. Okay. I'd say I'm experienced, so we're good there, but the other 46 being goal, that's why my project is failing.

Cornelius Fichtner (10:11):

Could I have done more to get executive support? Could I have done more to get the users involved and to get clearer business objectives? Sure. I could, but I really tried my absolute best to make this project work. Oh. And by the way, this is not the first time that my company has tried this. I'm actually the third person who's failing with this particular project. So overall I now understand much, much better why this project is failing. Let's take a few looks at examples of percentages. You know, I started out this search trying to figure out, is it really 70% of projects that file fail of IT projects? Well, I found on gantthead.com. I found an ad that said more than 60% of software projects in the United States fail and poor requirements management is one of the top five reasons. Okay. I found a paper on project success and failure.

Cornelius Fichtner (11:14):

What is success? What is failure? And how can you improve your odds for success in that particular paper? And I'll put a link onto my blog. They talk about 30% of it projects that fail. And I went back to the Standish report to the chaos report and I found the 2004 third quarter chaos spotlight. It's just a one page PDF giving you the basics of it. All they say 18% failed, 29% were successful. And 53%, which challenged. So according to the longest standing report that we out there still over half of 80 projects that we perform are challenged. Hmm. Interesting. Well, and just about as many different percentage numbers that you'll get, you'll get the same number of reasons why the chaos 10, like I said, starts out by saying the executive support. 18% of that is, is very, is, is the reason why projects fail.

Cornelius Fichtner (12:21):

So very big number on executive support there in Lorin J. May wrote an article called major causes of software project failures. And he starts out there by saying that poor user input is the first one that's going wrong. And then we have an article by James Jang, Gary Klein, and Joseph Balloon called ranking of system implementation success factors. Uh, that one appeared in the project management journal in 1996. Okay. Okay. That's a little while ago, but generally speaking, it's probably still standing what they say and they say, number one reason, clearly defined goals. So take your own pick. I mean, anywhere from what was it, 18% to 60% and any real reason that you can find, you can put it right there at the top of your list. Another thing that I realized as I was doing this little research here is, you know, project failure is a taboo.

Cornelius Fichtner (13:31):

I have yet to find a project manager who walks up to me and openly admits, you know, my project has failed. I have done my part in this and I have openly admitted my failure in a project. So I belong to these 18 or however many percent of it projects that fail. Now I want to hear from you, my dear listener, drop me a line, send me an email to PM This email address is being protected from spambots. You need JavaScript enabled to view it.. And tell me about your failed projects. Tell me why you think they failed. Tell me with which of the studies that I have mentioned here. Do you agree or disagree? Well, is executed support more critical than user requirements? What have you found on your projects? Why did they fail and what could you have done differently in order to not have them fail to be successful? But here is what I want you to do.

Cornelius Fichtner (14:32):

Most importantly, whenever I manage a project, my focus is first and foremost on people because it's people management really not project management. So tell me, how do you keep your sanity after a failed project? How do you motivate yourself to continue? Do you just shrug your shoulders and say, Oh, well you win a few. You lose the flu and you move on. Do you go out and get drunk with your project team? Or do you soak for weeks at end? Let me know how you deal with failure. What works for you? Because nowhere in all these studies do they look at the people behind the failed projects? I couldn't find anything on that. Nobody talks about the fact, well, this is stressful. This is annoying. This is aggravating. If you have a failed project, you have to admit yourself, you failed, you weren't as good as you thought you were.

Cornelius Fichtner (15:37):

How do people cope? How do we project managers cope? Because after all, if the statistics are true and depending on which one you believe three out of 10 project managers will face a failed project. And somehow they get over it. They continue, they move on to the next project. But what is the process? How do they get over it? What do project managers do in order to move on and go to the next project? And also what does this mean to their career? I mean, how do people look at them in the future, in the same company? Well, he's not a failed project. Can't be much good County. Drop me a line, a PM This email address is being protected from spambots. You need JavaScript enabled to view it.. And tell me what you think even better. If you have the opportunity to make an MP three recording, make about a one to two minute recording of your thoughts, send it to me. And I'll be more than happy to put you here on the project management podcast for that.

Cornelius Fichtner (16:40):

Yeah, that's about it for today. Thank you very much for listening in my next show, I will go back to the promised review of my third day after 2005 PMI leadership seminar in Toronto, as always, you can find us on the This email address is being protected from spambots. You need JavaScript enabled to view it., or you can send your emails to PM This email address is being protected from spambots. You need JavaScript enabled to view it.. And finally, we have this today. It's a quote from Jones and capers book patterns of software systems, failure and success. There are myriad ways to fail on a project, but there are only a few ways to succeed with that. Let's all stay on the path to success and sanity until next time.

Above are the first few pages of a computer-generated transcript with all its computer-generated quirks. A human-generated transcript is available to Premium subscribers starting with episode 136.