Developers, project managers, and product managers can all learn from project failures to build more successful products in the future.
More than half of IT projects fail, some research shows, for a variety of reasons spanning from poor idea generation to a lack of communication. However, that doesn't mean that organizations aren't making progress or learning from these failures, experts say.
Part of the issue is how an organization defines "failure," said Thomas Murphy, a senior director analyst at Gartner. Often, reports on the subject consider projects to have failed if they are late or over budget, which may be less of a failure and more of a case of unmet expectations, he added. "There are many reasons for this," Murphy said. "It is one of the reasons development has moved to more agile practices: Break down big 18 month projects into increments, which keeps everyone on the same page."
SEE: Project failure: 10 excuses your boss doesn't want to hear (free PDF) (TechRepublic)
This leads to a second type of failure: Not delivering what was planned. This is a failure of communication as well, Murphy said, as the requirements were not clear, were not understood, or changed over the course of the project. A move to agile can help with this, as it allows for more check-in points to see how the project and its needed are evolving, he added.
"Agile—if done right—should be a more collaborative approach to development, meaning that there is a close connection between the user and the development team," Murphy said. "Cloud and DevOps take this a bit further enabling me (with the right architecture and using facilities like Feature Toggles) to build a new feature/change and release it quickly to a small group, gain feedback, and move forward."
Generally, when we talk about project failure, we are referring to large projects, such as a move to the cloud, or a transition from waterfall to agile, Murphy said. "Large changes have lots of risks, have lots of unknowns going in, often are seen as being 'magic' or are seen through very simple lenses—if the developers 'do agile' we will be 10x faster—but these are not software projects."
Sometimes, a developer makes errors, and doesn't code the application to the specification, or has to interpret the specification themselves, said Christopher Condo, senior analyst at Forrester. Other times, products are not designed correctly, and there is a design flaw leading to a security, reliability, or scalability issue. Failing to test a product adequately can also lead to problems.
Performance failures also exist, when assumptions are made about how code will perform.
Often, success and failure are not binary, Murphy said. "We moved forward, we learned—that isn't 'failed,' we just didn't reach our destination yet," he added.
SEE: How to kill a project gracefully (free PDF) (TechRepublic)
How to avoid software project failure
Condo offered the following tips for developers to avoid common points of software project failure:
1. Meet with the product manager or product owner while you're writing your software development code. Walk through the logic of your code with them, and how you expect it to work, to ensure you are on the same page.
"It could be a 20 minute conversation that you have with this person about the business logic or the workflow that you're developing for them and to make sure that that actually is what they thought it was going to be," Condo said. "It still could turn out that when it's all operating, it's not quite what you wanted, but at least you've gotten that far and verified it."
2. Write tests that test the functionality, and the positive and negative cases to find any errors and vulnerabilities. Bring in performance tests as well to try and simulate the user experience as best you can.
3. Write clear, concise code so that any developer can look at it and understand logic flaws. "Have standards that your whole team follows about how methods and properties should be documented, where they should be in the code," Condo said. "You have to have oversight, you have to have code reviewers."
4. Welcome code reviews. When it comes to testing and reviewing, "don't take it personal," Condo said. "It really is about the business. You're working for a company nine times or 99 times out of 100, you're writing code on behalf of a company and that company wants the code to be done right. So, be open to having your code reviewed and be thankful when somebody finds something wrong with it."
For more, check out the How to become a software engineer cheat sheet, on TechRepublic
DevOps: A cheat sheet (TechRepublic)
10 free alternatives to Microsoft Word and Excel (TechRepublic download)
Choosing your Windows 7 exit strategy: Four options (TechRepublic Premium)
The 10 most important iPhone apps of all time (Download.com)
Must-read coverage: Programming languages and developer career resources (TechRepublic on Flipboard)