How to Succeed at Project Failure
I assume no one starts a project with the goal of having it fail. Then again, given the number of projects that do fail, maybe that's a bad assumption. Maybe some people not only strive to make their projects fail, but do research to ensure that failure. So, out of curiosity, I did a search on "how to make a project fail" and its cousin, "how to make a software project fail," and I found plenty of how-to's for the failure-bound.
Some of the advice I found keeps it simple by offering just a few key factors conducive to failure. One, for example, lists a mere three factors, such as that the team isn't really functioning as a team. Another cites just four factors, including unclear objectives and (hardly surprising) gaps in communication.
If you're determined to have your project fizzle, flop, and fail and these big-picture contributors are too high-level for you, much more detailed advice is available. For example, check out this article on 101 common causes of project failure. Thankfully, these 101 causes are divided into categories, such as leadership and governance, team issues, requirement issues, and estimation, so you can quickly zone in on the category of your choice.
Another article cites ten root causes of project failure, such as lack of executive support and failure to adopt a suitable project methodology. These ten root causes are followed by twenty symptoms of failure, such as lack of resources and unrealistic expectations. Lack of executive support is listed here too, making it both a root cause and a symptom of failure.
Of course, project failure is hardly limited to software projects. Furthermore, some projects that seem doomed to fail eventually succeed. Take the Big Dig, for example. This was a monstrously huge, insidiously complex highway reconstruction project in Boston that started in the 1980s and lasted more than twenty years. This project entailed building a temporary above-ground highway to handle traffic while the old, antiquated above-ground highway was removed in preparation for the construction of a below-ground highway. Given the contstant delays and the extraordinary cost overruns—to say nothing of design problems, engineering challenges, leaks, and much more—many people saw the project as a failure. But the project was completed and the new highway has been in use for ten years.
Of course, some projects fail because they never even get started. Consider one IT project for a marketing department. This particular IT department had a justifiably poor reputation with marketing, which had seen too many projects fail or fall short. With arrogance aforethought, the IT project manager for the new project went and named the project the Automated System for Accelerated Processing. Yes, ASAP! He sent a project overview to the marketing department. The marketing honchos saw the name ASAP, burst out laughing, and canceled the project.
If you'd prefer project success to project failure, be careful what you call your project. A rose by any other name can make or break it.
