At the root, there's no way to sugar coat it. If your software project goes off the rails and ultimately fails, it's always going to come down to a failure of project management. At some point in the process of scoping out, developing, and testing the software, something wasn't done, or wasn't done properly. However, that by itself is much too broad to be instructive, so here are the particulars:
Inability
Sometimes, there's just a mismatch. You get the wrong project manager for a project. Some projects just contain more moving parts than some managers can handle. It happens, and there's no shame in it. The real shame is in not having the courage to admit to that, and in failing to do so, run the risk of making the exact same mistake again.
Sloppy Development Practices
Even if the project management skills are there, unless you're using development best practices, you run the risk of having some aspect of your project jump the tracks while you're not looking.
Commercial Pressures
Sometimes, the pressure to get the software out “by Christmas” or some other arbitrary deadline is all but overwhelming. The problem is, development takes as long as it takes. If you try to force a project plan into a tighter deadline than the plan calls for, by definition, it means you're going to have to either add staff (and thus expense) or cut corners, or both.
Adding staff in mid stream introduces risk into your project plan by attempting to bring new people up to speed in an ongoing project, which can increase the likelihood of bugs in your code, and cutting corners can have much the same impacts. Shorter or nonexistent QA cycles, inadequate testing and feedback, and so forth. Yes, you may succeed in getting your project out by your arbitrary deadline, and it's almost never actually worth doing so in the end.
Use of Immature Technology
Don't use technology before it's been fully proven and tested, or if you do, try to account for that as best you can in your project plan and adjust end user expectations accordingly.
Unrealistic/Badly Articulated Project Goals
You can't create a “blue sky” project and expect it to succeed, and you can't scope a project badly and expect it to succeed. Failing to get this part right will plant the seeds for the project's failure early on, and make it all but impossible for you to even finish, much less produce an end result that people can live with.
Badly Defined System Requirements
Related to, but distinct from the unrealistic project goals. This comes in two flavors. In the first and most severe case, you try to design software to do a job without understanding the job yourself. That is to say, you can't code a new accounting program without understanding accounting and what their particular needs are. The second flavor is feature creep. If you're making an accounting software, ask yourself how much value add there is to including code that allows you to play multi player scrabble. If the answer is, there isn't any value to that, take it out.
Better still, design your processes in such a way that it never makes it into the design spec to start with.
