How does one define success and/or failure when discussing software development projects? Well, it depends on who you’re talking to. The end user’s definition of success will most likely be quite different than the business who is paying to develop the product. Let’s look at an example of what a business’s definition of success might be
The project meets the needs of the business unit at the desired price and the specified time frame.
Very few 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. The point here is that even with happy users, you may not get more work from the business because the person paying your bill might not like the cost overruns. I’d venture to guess that most software development companies would view this scenario as a project failure.
According to the 2014 Standish Group Chaos Report, out of the 175,000 software development projects that are attempted each year, 31.1% of them will be cancelled before they are completed and 52.7% will cost 189% of their original estimates. Clearly, the cards are stacked against you before you even begin.
So what types of situations lead to the ultimate demise of these software projects? The rest of this article will focus on four major reasons that many of these projects fail. Avoiding these pitfalls will help to greatly increase the likelihood of your next software development project being a success.
The Larger the Project, the Greater the Chance for Failure
Creating software involves trade-offs. No software is perfect. The larger the project and 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 it. Besides, if you release a minimal set of features the users will be better able to give you feedback and help you to identify 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 can make it more difficult for the user to get to the features that are used frequently and may cause confusion. They can also be a cause of additional bugs. Every added line of code is another opportunity to create a bug.
How can you make sure your software development project doesn’t get too big with too many unnecessary features? Listen to your client. Ask probing questions, and give your client the spotlight for at least 70% of the conversation. Make sure that you are truly listening to the answers they give you. They will tell you what they want.
Unclear Understanding of what the Software Should Do
It is important to give deep thought as to what you want to accomplish with the software. If you tell a builder that you want a building and give no other amplifying information, what do you think you would get? Would you get a house, a garage, an office building, or something else? About all you can be sure you will get is a floor, roof, walls, and doors.
Now suppose you tell them you want a house. With this increased specificity, in the US, you are likely to get a building with a kitchen, bathroom(s), living room, and bedroom(s). This is still far from enough information to be sure you and the builder are thinking along the same lines. You could be thinking the White House and they could be thinking a starter house. The more detail you give the builder, the more likely you are to get what you want.
This concept also applies to software development projects. The better understanding you and your team have of what the client’s expectations are, the greater your chance for success.
Writing detailed specifications with both functional and technical requirements will help to flush out exactly what the software needs to do. This ensures a more productive development team and less of a potential to miss out on important functionality that is important to the client.
Poor Communications between Team Members
Communication is key to ensuring that your project will be successful. It keeps you up to date with how the project is proceeding, and also shows the developer that you care about the project and are willing to get involved to ensure its success. Fast feedback to the developer is important for keeping things on track. It is also a means for holding the developer accountable.
Communications can be done through numerous methods such as phone, Skype, email, project planning or issues tracking tools, etc. The key is that you get regular updates and that you have a central place to keep track of features and defects. I require daily status reports from my developers even if it is only a sentence in an email. If a developer is not going to work on a given day that they are normally scheduled to work, I expect a quick note that they will be unavailable so I’m not trying to reach them to get an answer.
As well as providing frequent feedback, make sure that you are giving positive feedback when warranted. Developers like hearing good things. All too often, all the developer hears is “this is broken” or “this doesn’t work right”. Try to give at least as many compliments as you give criticism. It makes for happier developers who will try even harder to please you.
Wrong Developer(s) Hired
Hiring the wrong developer(s) can be a guaranteed death sentence for your software development project. When you are looking for a developer you should keep the following in mind.
• Experience
• References
• Communications skills
• Availability
• Cost
First off, the developer should be experienced. Experienced developers have already made a bunch of mistakes and hopefully have learned from them. The inexperienced developer will be learning on your dime. Experience will help them make the right tradeoffs for your situation.
While the new developer may be a quick learner and may be willing and eager to do the job at what seems like a good rate, you will pay for the inexperience in the long run. The odds of the project running way behind schedule and having hard to correct, costly issues after release will be much higher. You may find that your project costs you more; especially if you have to then bring in an experienced developer to fix the issues.