Introduction
This is a response to “How to make Software succeed” post by s1263235 [1].
The author initially presents a few cases of software failures ranging from complete failure with the entire project scrapped and resulting in a discontinued service – Google Buzz to project going over budget and delayed delivery – Universal Credit. The author then describes some issues that result in the possible failure of a software project and expresses their view of possible ways to resolve these issues to prevent or reduce the chance of software failure.
The three main criteria that a software project is often judged on in terms of its degree of success are: whether the project was delivered on schedule; whether development costs are within budget and whether the project meets the user’s needs in terms of scope and quality. My opinion is that when any one of these criteria are not met, the software is considered to have failed.
In this response post, I will offer my opinions on some of the main reasons of software failure listed by the author and discuss other potential problems that leads to the failure of a software project.
Project delivered late
The author stated that the delay of project delivery is a reason for the failure of a software project and possible ways to prevent this include careful design of the project; giving up on ideas which are infeasible to implement or following a reasonable schedule. I agree with this reason, as I stated above, this does contribute to the failure of a project. However, I would like to elaborate on the point of “following a reasonable schedule”. In large-scale software development, the schedule is often set by the project management team or even the stakeholders themselves. They usually do not have knowledge of the details of the software project and could set an unreasonable deadline which makes delivering the project on time difficult. A way to solve this problem to is to provide adequate training to the project management team so that they have an understanding of the software project and will then be able to do careful planning at each stage of the project to draw up a more realistic schedule.
Project ran over budget
I agree with the author’s point that a project which ran over budget is another case leading to software failure. The author states that estimating the budget that should be allocated to a project is a difficult task. To expand on this, since the estimation of the size and effort of a project is very difficult – estimating the size and effort of a project at the early stages is inaccurate (where estimation is actually useful) whereas estimating near the end of the project becomes fairly useless. This means it is often difficult to estimate an accurate budget in relation to the size and effort of the project. The overall result of this inaccurate estimation causes the project to run over budget.
There are some additional points that help reduce the chance of a project running over budget [2]:
-
Limit or reduce the scope of the project: we should concentrate on the main requirements of the project and limit the focus on adding additional features or functionality. However this requires careful planning as reducing scope of the project may not satisfy the user’s requirements.
-
Regular budget financial forecast: by having a budget plan before the start of the project and reviewing the plan on a regular basis during the project reduces the chance of the project running over budget. After conducting budget reviews, if the budget is constrained we may have to take out some functionality and reduce the scope of the project.
-
Resource allocation: when the budget is constrained, we could consider allocating resources to a part of the project that is less resource intensive.
Poor communication
The author also points out that poor communication between the customers and the development team as well as the developers within the development team [3] leads to project failure. I agree with this point, and my opinion is that it is crucial that the developers themselves are clear of their role in developing the software project, they have to work in unity and aim towards the goal of meeting the initial requirements of the project. Good communication allows them to resolve any misunderstandings and ambiguities in technical requirements as well as identifying other problems along the way.
An example that aid the communication between developers is the concept of pair programming in Extreme Programming (XP) methodology. This practice allows developers to work together and understand problems and specifications better. It is also helpful when a new member joins the development team, they get to know the project details when explained by another experienced developer.
Frequent communication between customers and developers are also important in order to capture requirements early on in the project lifecycle. In the XP methodology, the on-site customer practice means a customer is always with the development team. This means the development team can be notified of any changes to the requirements immediately and plan changes accordingly. The customer can write user stories to allow developers to gain further understanding of the functional requirements.
Other possible reasons
I will now provide a few reasons in addition to the author’s reasons of causes of project failures [4].
Inability to cope with a project’s complexity
Development teams that target towards new technologies or a specific industry are often troubled by a software project’s complexity. This is mainly due to inadequate knowledge of the field. The developers may not have any experience developing software for that particular area and the customers may not know exactly what they want from the software which results in incomplete requirements and specifications. This leads to the possible failure of the project.
A possible way to prevent this issue is to draw up a contingency plan which includes possible delays in the project; increase the budget allocated for the project should it require additional resources. However, this will only be helpful in the short-term to compensate for additional costs and delays but will not prevent catastrophic failures.
Use of third-party software components
The problem occurs when a development team uses third-party software components as part of their software architecture in the project. The third-party software components may be untrusted; not fully tested and have poor code quality. Using these components may result in security vulnerabilities and introduce bugs into our system. The poor quality of code will often result in developers spending a large amount of time understanding it rather than writing their own. Maintenance is also a problem, especially when the third-party software components are updated, all software components in our system that depend on those also have to be updated.
Conclusion
In this response article, I have highlighted some reasons of software failures discussed by the author; provided my opinions on those issues as well as added a few other causes of failures. Overall, I agree with the main point discussed by the author that software failure is very common in large-scale projects. However, with some careful planning and following the points described in this article can greatly reduce the chance of software failure.
References:
[1] https://blog.inf.ed.ac.uk/sapm/2014/02/14/how-to-make-software-succeed/
[2] http://project-management.com/what-to-do-if-your-project-runs-over-budget-and-how-to-prevent-it/
[3] http://blog.azoft.com/communication-within-software-development-company/
[4] http://blog.azoft.com/preventing-software-development-project-failure/