Description of the Problem
This post will analyze and describe the most prominent issues and problems that result in the failure of software engineering projects. In 2004, only 29%[1] of projects were completed successfully, motivating the study to figure out where the problem lies and what can be done about it.
Success in a project primarily revolves around the satisfaction of the client. However, if it not up to their judgment, when broken down, a successful project is one that is completed on time, within budget and meets all the requirements as specified in the design. Even small botches in any of these aspects could constitute a failed project.
A project can be classified in one of two ways; challenged and failed. A failed project is one that does not work, or has been cancelled. A challenged project has less brutal pitfalls, i.e. it was over budget, over schedule or has not implemented all of the necessary functionality.
The question then remains, what are the biggest troublemakers in software engineering projects that make their success rate so low and is there a foolproof way to ensure that a project will be a success?
Cause and Effect
The first thing I would like to discuss is what happens when there is an absence of leadership within the team, creating many problems in numerous aspects of the project. This would include a lack of direction with regards to design and planning for the project, potentially resulting in time wasting or the project going over budget. You need someone to make decisions should the team get stuck as well as someone to be able to manage the team and make sure all the members are doing their job and doing it right. It is also important that the leaders ensure that each and every worker understands exactly what it is that they are doing which is just as important and the leaders understanding exactly what it is the client wants.
Secondly, it is vital that a business case for the project has been made before the project has begun. This aims to measure the likelihood for success financially. If the return on investment is less than the cost to create and maintain the software, it is not worth doing. There is also a delicate balance that should be made between quality and budget. This means that an estimate building cost must be calculated at the start, and bad estimating techniques can also be a hazard for any project.
However, accountability is not solely on the leaders and managers should the project not be a success. Having personnel that are talented, get along well and work hard will significantly increase the chances of the project being a success. Therefore, hiring a team of well-trained and enthusiastic individuals will certainly increase the chances of the project being a success.
The next potential hazard is poor or non detailed design. Not having a clear, outlined plan from the beginning is setting the project up for disaster. This could result in certain requirements being forgotten. It could even be that the project moves completely out of focus and time is spent working on functionality that is completely irrelevant to the problem at hand. The functional and non-functional requirements need to be gathered and understood as well as any other constraints. Constraints could include aspects such as what technologies are available or what integrations are necessary.
Another potential concern for failure could occur when using external software not produced within the project. This could result from members wanting to use the newest technology on the market that has perhaps not yet been tested thoroughly enough. In reverse, perhaps by not having enough money in the budget to purchase what you need, therefore having to rely on mediocre alternatives. Any time that third-party software is used; the project runs the risk of running into some problems.
Unexpected problems, whatever they may be, may arise that could cause some failures. You cannot predict or plan for every scenario and sometimes a disaster may not be in anyone’s control or of anyone’s doing. This could include things such as the client changing their mind on requirements, benefactors pulling out their funding, or even natural catastrophes that physically damaged all at the work that had been done until then.
Personal Experience
When I have worked on a software engineering project, the success or failure of it usually relies on how hard the team or I have worked on all the aspects mentioned above. Making decisions about the design at the start was always extremely important and useful, as was having a leader to take responsibility should there be a conflict to make the decision themselves. Therefore, from my individual experience, I believe that design and leadership are the two most essential factors to aid the success of a project.
Conclusion
From the points and descriptions as stated above we can now try and summarize the closest to foolproof formula for success that exists in a software engineering project. Each aspect is an important piece in the project puzzle as can be seen in the graphic below.
Unfortunately, even though the project management style might adhere to all of these factors as best as they can, issues out of their control may still arise and lead to problems.
There are many reasons why a project can fail, some are unavoidable and some can have their likelihood of occurring reduced with proper planning and evaluation of every aspect of the project. A foolproof formula for success does not seem to exist but the team can try and minimize the risk in the areas outlined that cause the most problems.
References
[1] Comelio, P. (2008). Why Do So Many Software Projects Fail?. Available: http://www.slideshare.net/PhilComelio/why-do-so-many-software-projects-fail-25nov2008. Last accessed 7th March 2014.
[2] Connell, C. (2010). Why Software Really Fails And What to Do About It.Available: http://www.drdobbs.com/architecture-and-design/why-software-really-fails-and-what-to-do/223700002. Last accessed 7th March 2014.
[3] Outspeaking. (2014). Why Do Government IT and Software Projects Fail?. Available: http://outspeaking.com/words-of-technology/why-do-government-it-and-software-projects-fail.html. Last accessed 7th March 2014.