Developing computer software can be a risky business. Jeff Kenny, a consultant with Wynn Williams & Co, outlines some of the causes of problems and how to avoid them.
Many clients invest considerable sums of money in having computer software developed for them. The NZ Police "INCIS" project (Integrated National Crime Investigation System) heightened public awareness of the potential difficulties. What is less well known, is that these difficulties occur often. Developing software is a high- risk undertaking. The risks, and the ways of minimising and sharing them need to be clearly understood before embarking on any significant software development project.
In 1995, the Standish Group, which is a respected group of US researchers, undertook the largest ever survey of software development projects. The results were startling. On average only 16.2% of projects were completed on time and on budget. 31.1% of projects were cancelled.
The remaining 52.7% of projects were completed late, over budget, or delivered software that did not work as required. Of these, the average cost overrun was almost 200% and the average time overrun was over 200%.
The results were similar for both public and private sector organisations. The results were also comparable for large, medium, and small size organisations.
These results are by no means unusual. Last year the New Zealand Institute of Economic Research in conjunction with the Simpl Group, which is a group of New Zealand researchers, carried out a similar survey. The results were broadly similar. 32% of projects were completed on time and on budget. 66% of projects were completed late, over budget, or delivered software that did not function as required. The rest of the projects were cancelled.
These surveys contain some guidance for clients who wish to develop computer software. They clearly show that there were four key contributors to software development projects failing. These were:
a lack of involvement in the development process by the ultimate user of the software; the requirements that the software needed to meet were not complete; the requirements that the software needed to meet kept changing; a lack of management support.If building a house can be used as an analogy, the house would be built without regularly talking to the person who would live in it, the plans would be incomplete, the design would keep changing, and the owner would not be interested in the project. It is little wonder that these projects ran into problems.
How then, can these problems be avoided or minimised? There are a number of things, both procedural and legal, that can be done.
The client needs to be fully aware that software development is inherently risky and will remain so until software development matures as an engineering discipline. The client needs to know that there is a high chance of problems occurring on their project. In other words, the client needs to be wary of the risk.
The client's management must establish a good realistic business case for the project. Is the project feasible? What business processes will the software improve or eliminate? What costs will the software reduce? How will the software improve the organisation's business capability? What will the client's return on its investment be? What are the alternatives? Establishing a good reason for the project is a critical step and should not be overlooked.
The client should have a senior manager or employee who takes responsibility for the project. That person should know what the client is trying to achieve from the project. He or she must thoroughly understand the client's operations and have a reasonably good understanding of what the software will be realistically capable of doing.
The client should look to re-engineer, or at least review their business processes before the software development project. This will not only make the software requirements easier to specify but will often simplify the software design.
The client should look to break the project up into small steps so that various software components are planned, specified, built, tested, and implemented as part of each step. Steps that have a high chance of failure should be identified and attempted first. This means that if the project is to fail it will do so early with less dramatic cost consequences. It will also mean that the software requirements are easier to specify and that the software will be easier to change.
The client should sign a written software development agreement with the developer before the project begins. Often the software development agreement is an afterthought and it is difficult for the client to negotiate changes to it because the project has already started. The time to negotiate the terms of the software development agreement is before the project has started. Then the client can look elsewhere if it cannot obtain satisfactory terms.
The client should ensure that the software development agreement promises what the client expects. One particular aspect of this, whilst not entirely unique to the software development industry, is important in light of the risks inherent in software development projects. Software development agreements often contain warranties and exclusion clauses favourable to the developer and therefore of disadvantage to the client.
A warranty is an assurance that a particular thing is true. When negotiating software development agreements clients should generally seek broad warranties that:
the software will meet the client's requirements; it will work with the client's other computer systems it will not breach anyone else's intellectual property rights; and the developer will do the work using proper care, skill, and diligence.The developer, on the other hand, will look to limit its warranties as much as possible. As a result, the warranty provisions may not accord with discussions that have occurred between the client and the developer about the performance of the software. Clients should be wary of this and seek to avoid it if possible.
Exclusion clauses are used when a party to an agreement is unwilling to accept full responsibility for breaching the agreement. The exclusion clauses may purport to avoid liability, cap liability to a sum of money, or limit the time period in which a claim may be brought. Again, clients should seek to minimise these clauses. Developers on the other hand will seek to include broad exclusion provisions in order to minimise their risk.
Warranty clauses and exclusion clauses should be viewed for what they are - devices for allocating risk between the parties. They should not create a blanket exemption from liability for the developer unless the client is comfortable with that. Instead, the provisions should allocate risk between the client and the developer clearly, and provide for what is to happen if the software does not meet the client's requirements. That may include obligations to correct software defects, compensation by way of price reductions, and limiting liability for downstream losses should the software prove defective.
Software development will remain a risky undertaking for clients. However, clients can reduce their risk by having a good understanding of the risks and taking certain steps. How the remaining risks are shared between the client and the developer should then be set out in a written software development agreement before the project begins.
© The Lawlink Group Ltd 2001
Every effort has been made to ensure that this information is accurate. However, it is general introductory information only. It does not constitute legal advice and should not be relied on as such. Specialist legal advice should be sought in particular matters. Any reference to law and legislation is to New Zealand law and legislation.
Jeff Kenny is a consultant with the Christchurch Lawlink firm of Wynn Williams & Co. His main areas of practice are company law, commercial securities, Securities Act matters, commercial property, joint ventures, and trusts.
Website
Wynn Williams & CoEmail: jeff.kenny@wynnwiliams.co.nz