5 Ways to Make Sure your Project Fails

Software projects fail. If you’ve worked with a company for long enough, I’m sure you have seen at least one project that didn’t make it to the release phase. There have been reports) saying that as much as 31% of projects fail. But why do so many projects fail?

Today I’m going to look at things a little differently. Instead of telling you what you can do to prevent your project from failing, I’m going to tell you what you should do if you want your project to fail.

Sitting down with your client and taking the time to get the requirements for your project is unnecessary. The time that you save by not doing this can easily be used to develop more features for the project. Why should you talk with the client when you could be spending the time programming?

Sure you may not be writing the program that your client wants and you may be adding in unnecessary and unwanted features, but you’ll have more time to fix that down the road when the client tells you they don’t want the features.

Did you hear about the latest source control? You should definitely use it for this project. It doesn’t matter that your developers have no idea how to use it, or that it doesn’t have nearly as many features as your current source control. It’s the newest product on the market and that must mean that it’s the best, so you should adopt it to stay ahead of the curve.

The above thinking also applies to software practices. Just because your company generally follows the Waterfall development method doesn’t mean that it should stick with it. For this project, try out Agile methodology or some other software development practices just to see which one is best.

Source control is a waste of time. We only hire the best developers, and they never make mistakes. If they have to waste time checking in revisions, tagging code and using branches they won’t get as much programming in. If any bugs do creep into the software they probably won’t be that large and fixing them will be easy. Instead of source control we’ll just backup the source code every couple of months.

Communication isn’t needed in the development world. All programmers communicate in the same way so there isn’t any reason to learn how each individual developer communicates. We’ll have one meeting at the beginning of the project to tell the developers what we’re making, one half-way through to make sure everyones on track and then a meeting after we’ve delivered the software to the client to congratulate everyone.

What’s the point in documentation? Our developers don’t want to write it and I’m sure the client will never need to use it. Our code is self-documented anyways so further documentation is pretty much useless since it will just add extra work on our developers. If we just write better, more self-explanatory code we won’t need to document and both the developers and the clients will be happy.

In case you haven’t noticed yet, I’ve been extremely sarcastic throughout this entire post. Everything I’ve said here should be avoided at all costs unless you really do want your project to fail. In the following weeks we’ll go through each of the things mentioned here and tell you what you should do if you want your project to be a success.