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.

Don’t ask for requirements

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.

Introduce new technology into your development process

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.

Don’t use source control

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.

Poor Communication

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.

Don’t bother with documentation

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.

If you like this post then why not share it?
  • StumbleUpon
  • description
  • Technorati
  • Digg
  • Slashdot
  • Design Float
  • del.icio.us
  • TwitThis
  • Reddit
  • E-mail this story to a friend!
Add devjargon( ); to your RSS Updates.

Get new posts sent to you by email for free!


  1. 1 06.22.08
    11:27 pm

    One thing that I have found that makes projects fail is when managers add new developers on late into the project. Not only do you have to take away developers to train these new people it also adds to the frustration.

    If the new developers lack knowledge of any software tools that you are using you’ll have to train them on those. Its just annoying.

  2. 2 06.24.08
    8:07 pm

    This is a great article and, being a web developer, I agree with all these points. My favorites are definitely #1 and #3. Another reason that projects fail were in this post on Coding Horror. Both the article and the comments are really valuable:


  3. 3 06.24.08
    11:12 pm

    That article is a perfect example of anohter reason why projects fail. When developers code a large chunk of the system without letting other developers in on the process you quickly see projects going down the tube.

    This is often a problem with integration. Everyone always says that their sectio of the project is done and they just have to “integrate” with the others, but this often takes the most amount of time. When developers don’t communicate with one another, projects fail.

  4. 4 06.25.08
    12:54 am

    Interesting look on why software projects fail. #2 and #3 definitely ring home.

  5. 5 06.26.08
    12:22 pm

    I think not bothering with requirements is a very easy hole for newer developers to fall in to - especially in the web design sector, from my experience. Requirements and a functional specification make it clear what features will be implemented, and which ones want - they prevent unnecessary stress and communication with the client, which can then be used to discuss more important areas of the website/project.

    When writing a specification for a larger project now, we point out milestones in it where we’d like the client’s input: for long-term ongoing projects, this could be once a week, or once every two weeks.

    Good article!

  6. 6 06.30.08
    12:14 pm

    [...] of a group than the developers. Setting unrealistic goals is one of the easiest ways to make sure a project fails. If you set goals that your team won’t be able to meet, it will only hurt morale and damage [...]

  7. 7 07.09.08
    9:02 am

    [...] details of how the project is created, they may forget functionality that they want, and this is a great way for a project to fail. When you sit down with a client make sure you keep your sentences as non-technical as possible and [...]

Leave a Comment