Unfortunately, a large percentage of software development projects fail. These statistics can often be daunting to someone taking on a new software project. That’s why it is important to understand the definition of failure as it is different for every project, and is based on who is defining the success or failure. For example, to a business, the definition of failure might be
“The project does not meet the needs of the business unit at the desired price and in the specified time frame.”
How many projects do you think meet that definition? Very few software development projects succeed on all of those fronts – functionality, time, and money. You could in fact fail by that definition but still have many happy users. They may love the program and not know that the program cost twice as much as was budgeted. So the majority of the people may not even know that it failed. The point here is that even with happy users, you may not get more work from the company because the person paying your bill might not like the cost overruns. All this is to say that failure is hard to define, and you have to look at it from many perspectives in order to truly define whether or not your project is a success.
In addition to things like happy users and getting the project done on time and on budget as promised, you must also be a winner in the deal. If you were not compensated sufficiently, then would you call it a success? When dealing with your clients, employees, and vendors, you should always be looking for win-win scenarios. It is never good when one of the parties feels like they have lost.
Creating software involves trade-offs
No software is perfect. The more features you add, the longer it will be before you can release the product. Many companies spend so long in developing the product that they run out of money before they can release the product. Besides, if you release a minimal set of features and get it into the hands of your users, they will be better able to give you feedback and direct you in what features are most important for the next release.
It boils down to whether the user would prefer to have good, working software today or perfect software at some point in the future.
Know when to stop
Adding too many features can be as bad as adding too few. These added features that may rarely be used can make it more difficult for the user to get to the features that are used frequently. They may also cause confusion and can be a cause of bugs. Every added line of code is another opportunity to create a bug.
Listen to your client. Ask probing questions. Give your client the spotlight for at least 70% of the time during initial conversations and listen to their answers. They will tell you what they want.