Why Projects Fail, Part 3

This is the third and final installment of Why Projects Fail. So far, we’ve covered two important points. First, sometimes projects fail simply because they are hard and people underestimate them. You need to assume a level of difficulty when entering a project that affects an entire organization. Second: plan. Many projects fail because the organization didn’t invest in a plan that was thorough and realistic. Optimism is great, but don’t let it get in the way of making realistic decisions. The remaining reasons that projects fail include:

Project failure is expected
It’s pretty well accepted that most projects fail.  You can find studies that estimate 30% to 80% of projects fail. Isn’t that incredible? Is that okay? Would you be okay if your organization failed at fulfilling its mission 80% of the time?  Let’s face it, this project is part of your mission. Geneca, a software consulting firm, surveyed 600 business and IT executives as part of a study of why project teams struggle. You can guess the outcome based on the name of the report: “Doomed from the start.”  Geneca’s finding was that “75% of respondents admit that their projects are either always or usually doomed right from the start.”

Why Projects Fail, Part 2

Last time, we ended with the question: “Why don’t people plan enough?” For one, planning requires a healthy dose of pessimism, and who likes a pessimist? I’ve experienced this situation many times.  The project team is sitting around the table planning what you are going to accomplish and how.  Everyone is excited and has high expectations for the project.  The team discusses the project objectives: “Fundraisers have instant access to reports and solicitation plans,” “we have a single source of information – the website, ticketing system, finance system, call center, registrar’s system (you name it), are all integrated,” “a policy and procedure manual is actively maintained and used by staff.”  These are all great objectives.  The next step is to talk about how the team will accomplish them.  You create deliverables – the stuff the project will create – to fulfill objectives.

Let’s use the policy manual as an example. A good manual takes time. We estimate how long it will take and then assign resources (i.e., the people that will do it). Often, these resources are client staff. Sally, the head of Development Operations (she is great and really excited about implementing the new system and totally gets the importance of the manual) is the obvious resource for this and she wants to do it. She will need to invest 100 hours over the life of the year-long project. She understands and is on board. But Sally has a fulltime job already as the DevOps Director. 

Why Projects Fail, Part 1

At JCA, we do project work for nonprofit organizations.  We’ve been doing it for more than 20 years for hundreds of nonprofit organizations.  I’ve been doing this work personally with JCA for the last 11 years.  I’ve been involved in a lot of projects, both as a participant and a leader.  I’ve seen success and I’ve seen failure (is that a James Taylor song?).  Every project teaches me something about how to make them succeed, but I must admit, I’ve learned more from the failures than from the successes.  As our COO Steve Birnbaum says, “A barrel of ‘attaboys!’ don’t add up to one ’aw crap.’”

Talking about why projects fail is nothing new.  There are many articles and blogs on the topic, most of which say the same basic thing, and I encourage you to read them.  Most of them are right, and I may repeat a few of those things here.  My goal is to share with you, over the course of this three-part series, what I’ve learned running projects at nonprofits across the country.  There are so many reasons a project might fail, and it’s never the same one for all, but here are some things to think about.