Success for all software projects*

(*success not guaranteed, side effects may include going over budget, over time and delivering the wrong product)

This is a response article to “How to make Software succeed?”

In the original article the author identifies that, in addition to some of the more traditional reasons for software failure, there are issues that can lead to software failure post-delivery. He then discusses a few major software failures (Google Buzz, Universal Credit, Pac-Man), common reasons for failure and proposes solutions that would make software projects successful.
Just to remind – a software project is considered successful if it is delivered on schedule, development costs were within budget and  software meets the needs of users, in both scope and quality.

I disagree with some of the solutions proposed by the author as those methods do not guarantee success nor are they applicable to most organisations. The author also did not address all issues he mentioned in the introduction and in his examples.

Failures/Solutions discussed in the blogpost

Project runs over time

To begin with, I agree with the proposed solution of having the core of the project implemented before writing additional features. This way even if feature creep occurs later on in the project, the core functionality will still be present and unfinished features can be dropped or scheduled for the next release, ensuring the project is delivered on time.

However, I do not think it is an easy task to “make a reasonable schedule”. First of all, there are various stakeholders in each software project and they want the project to be released as fast as possible. Only a few select companies have the luxury of releasing a product ‘when it’s ready’. For the rest of us, it is not the question ‘When can our developers finish this product?’, but rather ‘Can our developers create this product before this specific date in the future?’. It is the role of a manager to estimate whether the question can be answered positively. Even then, most companies think their schedule is reasonable at the beginning of the project, only to be proven otherwise later on.

Next, the author proposes conflicting ideas of “carefully design at the very beginning” and “give up some bad idea, before it is too late to do so”. While the former statement proposes a carefully planned design, one which is most often employed in the waterfall model, the later one suggests releasing a prototype quickly in order to see if the idea of the project is feasible at all (more common to agile and other modern methodologies). To “carefully designing a piece of software at the beginning” is already in itself a large commitment, where the project has been agreed upon and backing out would have negative consequences.

Project runs over budget

The author claims “be realistic, make the budget based on the full requirements”. Again, the same argument as before can be applied. The developer team has to decide if they can produce the software given a certain budget. Projects run out of budget because the estimates made at the beginning seemed reasonable enough, not because the team knew they were going to use twice the budget, but still decide to do the project.

The claim “work  with team which has record of delivery within budget” means that either the team is very efficient or that they are good at estimating the cost and do not accept projects they estimate they can’t complete. This further assumes that there is a team which has record of delivery within budget, but it is not always the case, especially for new projects.

Poor communication

I do agree that the team and the customers have to understand each other. I would like to add that is not only important to talk to your customers early, but to continually get feedback, as further clarifications can be needed, and software scope can change ever so slightly as time goes on.

Never reviewing project progress / Inadequate testing / Lack of quality assurance

I grouped these together as they all relate to the same problem – product does not meet the users needs in terms of quality. The author proposes that the solution to not reviewing project progress, not testing and not writing documentation is to actually do all of those things. While it is an obvious solution, the problem is in itself a little different. It is not enough to schedule some time for all of these actions somewhere in the future, testing and writing documentation have to be done continuously, as the code is being written, not sometime later. If the project is already behind schedule, leaving testing for later can lead to testing being dropped as the project is being rushed through the door (same for documentation). Furthermore, you simply cannot  test after “product has been released, before you actually get feedback or a complaint from the user”. If bugs are severe enough, the project will now either be way over time or it will not have met users quality needs. In either case, the project will be a failure under our definition of project success.

Failures not discussed

The author mentions that public opinion and competition can cause the product to fail after it has been launched, but does not pursue these problems further or give possible solutions to them. In the case of Google Buzz, they provided a product similar to the one that was already on the market and fairly popular. They did not, however, add much additional value for the users (some would argue it provides less value), and therefore users had no incentive to switch. Since they did not have the first-mover advantage, they should have made a product that is in some regard ‘better’ than the original.

Similarly, having the wrong idea for a product from the start will cause it to fail, no matter how brilliant it is in regards to technical aspects or how well known your company is. There is no solution to this issue, you can only mitigate the cost of failure by releasing a prototype early and based on the initial interest, continue or move on to the next project.

Conclusion

In this article I have discussed the proposed solutions to causes of software failure made in the post “How to make Software succeed?”. I do not claim to know how to make every large scale project succeed (no one does, really). However, some solutions proposed by the original author are just not applicable in a real world scenario or do not tackle the cause of failure appropriately  I have also expanded on the point made by the author that projects can still fail even if all technical aspects are in order, due to external circumstances.

One thought on “Success for all software projects*”

  1. Thanks for your response. I do agree the points you claims and yes, sure, no one can guarantee the success of a software project, since there are just too many side effects.

    Besides, I need to accept that my article was really not well organised, I didn’t explain the reason why I included those failure example(whereas some of them should be response to the point I listed in the Introduction section, especially those “un-traditional” ones) and also I didn’t explain my idea clearly. I wrote another article before this one, and found out that one was actually not related to “long-term, large scale” software just one night before the deadline, and rewrite this one. That’s why this article is so crappy 🙁

Comments are closed.