Register Advertise with usHelp Desk Today's Posts Search

Rate this Entry

How To Fail A Software Project

Share
Submit "How To Fail A Software Project" to Facebook
Posted 3rd July 2013 at 09:07 AM by MobiDev



There might be even more ways to fail a project, than to make it succeed; and this can be achieved with less effort. First we have to define a failure: it's either if the project is never finished (including the cancellation); or it fails a critical deadline; or the software is of remarkably bad quality; or the spent budget is beyond reason. Of course, there may be various combinations of these. Failures have a huge rate; and so much depends on software owners, rather than the chosen developers. So, how can you make your software project sure to fail?

1) Start the project being unprepared
There a certain steps you should take before turning to software developers. You have to transform an idea into something tangible, gather information, create documentation (such as specifications), think of your budget, deadlines, think how the app will bring you profits; most essentially, form the clear purpose of the app. A software project needs thorough, careful planning; to fail, just abandon it.

2) Keep the purpose of the app unclear
You might not know what you want yet; you might not understand what exactly the future users want and need. That's a common occurrence among inexperienced client. Let's imagine, from now and on, that you chose a really great software contractor for the project. Such contractor can help you overcome this uncertainty, and provide you with all the necessary consultations. But if the goal is to fail, don't help them to help you. Don't clarify what you want, don't disclose your vision of the product, and what it must do. The contractor may give you a vital piece of advice that might substantially improve your product - just reject everything.

3) Neglect communication
Not only you have to keep the purpose unclear; the general tip for causing troubles in software projects says: neglect communication along the way. Don't specify the target audience; suffice it to say "the app is for everyone". By no means involve users into the process: they can help you form a clear picture of what they want in an ideal app. Put communication aside, and you are already halfway to failure.

4) Try a fixed cost for a complex app
Fixed cost hides a lot of pitfalls; it's fine for simple projects, but with complex ones it may not work out. The project may end up with overpays, inflexibilities in the course of development, and, as a result, low quality. Fixed cost does not motivate developers to throw their forces and get a better result; the product is made just enough good to make you accept it.

5) The more you change requirements along the development, the better
Even better if you make them incomplete. However, your software development company will do their best to form detailed requirements even before the earliest stages of development. Agile methods presuppose handling minor changes along the way; however, dramatic changes in requirements can do their job of wasting budget and inevitably getting beyond the deadline.

6) Set an inappropriate schedule

This means of failing a project works, but it's too avoidable to be efficient. That's because your software contractor can give a relatively precise estimation of how long the project would take. But it can work if your unrealistic deadlines are accepted by developers. Such a schedule works great in combination with changing requirements. Together they can guarantee failure; either missed deadlines with working software, or the software is delivered on time, but has poor quality and/or multiple bugs, simply because there was no time for proper testing. There is place for a combination of these two.

7) Fix it later (or maybe never)
Setting an improper schedule gives way to another efficient means of failing - deadline above all; and if there is no time for testing, roll out what there is, and all the possible problems will be solved later. Unreliable product is quickly abandoned. Let your users test it in the field instead of QA specialists. Reject support, and the software product will quickly get outdated. Leave no chance for user feedback. When users get not what they need, they are quick to abandon it in favor of something really worthy - just perfect to call it failure.

8) Forget about promotion

Okay, you have finally received the product, good or bad, within or out of deadlines. Here you can deal the final coup de grace - forget about any promotion and marketing strategy. A perfect way to initially roll the software product into oblivion, where it'll never be found.

These are the basic principles of cooperation between you, your developers and your users, that can help you fail the project in the abovementioned ways. Software projects don't fail because of limited budget or strict deadlines. They fail because of wrong expectations and lack of planning, as well as rejections of vital advice. But knowing these ways to fail a project, it becomes quite easy to avoid them, and go for success instead of failure. What would you choose?


- See more at: http://mobidev.biz/blogs.html
Views 929 Comments 0
Total Comments 0

Comments

 


All times are GMT -6. The time now is 10:47 AM.