How to Ensure Your Project Fails

There are plenty of ways that a project can be considered a failure. Some are more subtle than others, and may depend on the kind of software being developed and the individuals involved. Common types of project failure are:

• Over budget – The project is finished, possibly before the deadline, but cost much more than expected. This may not be such a big problem for large companies, but for a small business with a tight budget, it can be disastrous.
• Late delivery – The project is finished, but this time it is later than initially promised. Again, this may not be a fatal problem for a big company. For some people though, it can be so bad that a day late is a day without food on the table.
• Lack of promised or essential features – If you promise your software will do something and it doesn't, then that's a pretty big problem. This type of failure may be a symptom of trying to avoid either (or both) of the problems above.
• It's not what the client wanted – Similar to the above, although it's more likely to be caused by bad specifications than by poor scheduling.
• It doesn't sell – This is another type of failure that can kill an indie developer. Failure to sell can be the result of poor market research, a lack of marketing or a plain sucky product.
• It's cancelled – This one is pretty obvious. A cancelled project can be a sign of any number of symptoms, from bad management to a lack of resources.

Now we know the types of failure, let's see what we need to do to achieve them!

There are plenty of things you can do before the project starts to make sure that it never succeeds.

• Ignore client requests – If you're working directly for a client, make sure you ignore what they ask for. After all, you're the one who knows how to create software, right? You can score bonus points here by mocking them, pretending to listen whilst doodling, or blinding them with jargon.
• Create fuzzy requirements – If you must create a list of the user's requirements, make sure they're as generic as possible. Don't bother detailing what features the finished product will need, because you might want to change it later. Also make sure to include as little detail as possible, and leave the requirements open to speculation. If someone has to ask for clarification on what a feature does more than once, you know you've done your job.
• Don't put effort into design – Design is for hippies, so make sure you only vaguely describe a few bits of the software. Make sure to leave out details on the most important features, and definitely don't describe how people will use the software. Include a few designs scribbled on a beer mat, so you look like you're completely devoted to the project.
• Implement the least important features first – When the client sees you've gone to the effort of implementing some of the least important features, they'll think you've gone the extra mile. Make sure you escape before they realise what you gave them is just a husk of a product. Bonus points for using a smoke bomb in your escape.
• Schedule your time poorly – We all know you're such a cool programmer that you can write a 3D engine in a few days, and that the AI routines are a three hour job for you. Make sure the schedule reflects how awesome you are.
• Swap people around – If you have more than one developer, make sure they all work on something they're least proficient at. After all, this will help them get better, so you're actually doing a good thing!
• Don't specify the level of quality you're aiming for – Your product will totally rock, so don't bother setting any quality goals.

• Don't use source control – There's no point in wasting a few hours setting up a source control system, because nothing bad will ever happen to your code.
• Don't organize yourself – Once work has begun, don't bother interrupting the flow by reviewing your project's progress. Remember – Everything will be all right.
• Ignore ready made components – There's a plethora of well written, fully tested components that can be integrated into your software. Using them will shave precious time off your schedule, and allow you to actually get the damn project out of the door. They're your worst enemy, and you should treat them as such.
• Make everything more complicated – If there's a choice between writing a small module that implements all the functionality you need, and writing a huge set of modules that uses all the latest design patterns you've been reading, you know which one you should choose. Bonus points are awarded for refactoring your code so that each method is only three lines long.
• Don't track bugs - Keeping track of bugs makes it much easier to eliminate them, and that would mean you'd have to waste time fixing things instead of creating cool new code.

Don't panic if your project has actually been completed on time and under budget. There are still plenty of ways you can make sure it never reaches its full potential.

• Don't promote it – Your product is so good, it'll sell itself! Don't ignore the fact that marketing is one of the largest factors in a project's success. Just make sure you do as little as possible. Try including a link in one of your forum signatures, and that should be enough.
• Don't support it – Don't respond to customer emails, and ignore any requests for help. Feel free to add a wiki to your website, and tell people that if they don't know how to do something, they should add it themselves. Remember to be as rude as possible.
• Don't improve it – Once your product is done, it's done. Don't waste time refining it, because we all know that good software is written in one go.
• Ignore feedback – If someone suggests an improvement, no matter how small, you should ignore it.

Remember The real challenge with helping a project to fail is making it look like you tried your best to prevent it. Be as creative as possible when thinking of ways to help your project to its demise, and you'll soon be celebrating a complete disaster.

Check out the developer articles section for more articles on project management, marketing and business improvement.