Software Contracts

Software Contracts Quality assurance for IT investments Luiz Wolf Software Contracts Quality assurance for IT investments By Luiz Wolf 75% dos investimentos são utilizados para manter o legado e 25% são aplicados em novos projetos Desenvolvimento de novas aplicações Gerenciamento e Administração 25% 9% 38% 28% Operações, Rede, Suporte a usuário Manutenção de aplicações Considered by business managers as a nebulous area, with poorly understood controls, Information Technology (IT) is frequently considered an inevitable evil, due to the increasing need, within the companies, of automating and optimizing their processes, in order to decrease costs and increase their revenues. This perception about IT is not always wrong, as even the CIOs of such companies have a difficult time when trying to carry out their projects within budget and in a timely manner. A distress situation is then created, because the IT consumers, who must implement technology projects to improve the performance of their business areas, are not comfortable enough to invest in IT, and finally choose any other alternative solution. On the other hand, the CIOs are not able to implement projects to improve IT quality and productivity, due to the lack of investments. We must change this vicious circle, but we must have first proper focus and metrics to allow the company to recognize the benefits that ITassociated actions can bring. It is crucial focusing the control and improvement efforts on the areas with higher costs. The Hardware account was the main resource consumer in the past, but has now been replaced by the software systems. As we can see in the chart that follows, most of IT resources are spent with the maintenance and new software projects, while the infrastructure is the cheapest area. It is worth reminding that the infrastructure expenses (hardware, network, etc.) are usually related to the kind and quality of software produced or purchased by the company. Figure 1 – IT investment per area – Source: CSC – 1 2003 The percentage invested in software systems can vary according to the company’s business area and projects, but everybody agrees that the expenses of this area are really significant. The companies choose several development and maintenance modes for their systems; the main ones are the following: • • • • • In House with the company’s own resources In House with outsourced resources Outsourced development Purchased packages Systems as services (ASP) All these modes are usually found in the same company – including the purchased or ASP software, as it requires expensive customizations, with costs that can be higher than the original software. In some cases, there is the false idea that with off-the-shelf software the company will make no additional development & maintenance investments. However, the practice shows that such investments must be always made, although with lower values. If the IT area is so critical, we can wonder if the control on the contracts is really effective. Can we evaluate the products and services of suppliers? In fact, even those companies that adopt only the internal development mode for their software should have their contracts established between software consumers (user areas) and suppliers (software development departments within IT). When we mention outsourcing contracts, most of times the goal is to assure service level agreements (SLAs), costs and scope, without any reference to quality. But the scope defines the deliverables and tests are required to confirm that the software is fully functional. This is a great 1 These CSC charts refer to a given segment of American companies. conceptual problem, a source of discontent for those who make contracts: is the assurance of a functional software enough? It is not. As any other purchased product, the software must be functional, but it must be perfectly functional above all. To be perfectly functional, the product must be well designed, well analyzed, well built and well implemented. All such phases should be analyzed as to quality and use of best practices. IT projects usually exhibit a long payback period, which only increases the importance of validating the entire process, avoiding customer dissatisfaction. 70 60 50 40 30 20 10 0 1 Year 1 - 2 years 2- 5 years “...if the project assures an independent check effort, an organization in charge of conducting and checking must be selected. This organization must have its independence and authority assured to perform the check activities.” (ISO/IEC 12207, 1995). Figure 2 - Payback periods for IT projects (two sources) – Source: CSC – 2003 Some companies even mention in their internal or external contracts that besides being functional, the software must be developed according to the best practices: “ …the provider must assure that the deliverables follow the best technical practices in the market…” Figure 3 – Contract clause that addresses the Best Practices The outsourcing of technical control related to software quality is an important choice, considering that there are companies with specific pieces of software – most of them in the software functionality check area; only few of them, however, have validation solutions from system architecture to implementation, and not all of them offer independent services. The frequently used CASE tools increase developer and designer productivity, but do not assure that they are adopting the best practices. In some cases, the incorrect use of such tools can even worsen the lack of quality, because they are easy to use and can create a kind of “mental laziness” in their users. The CASE tools are not an inspection product. Is the use of inspection software enough? No, because the software will not operate on its own. We must register procedures, the company’s specific standards, DBA, DA and architect rules, in addition to the creation of approval criteria, the improvement of validation at every new project, notification of achieved gains and training; in summary, we must administer the control and assurance of software quality. The system development, acquisition and maintenance methodologies are not inspection tools too. They must include, in their processes, quality validation phases for the produced technology items; without any inspection, however, the user of this methodology will probably create items with the required format, but with a content that is incompatible with the project. “Formalized methodologies can be more a placebo than a process to improve development quality. Some developers justify delays and lack of quality based on the claim that the “proper” practices had been followed. As a result, the developers frequently exhibit the tendency of being victimized by goal deviation, following the methodology in detriment to the development of real systems – a typical case of mistaken values.” (Fitzgerald 1997) Which are the best practices? What happens if they are not followed at all? How are they measured? Who checks if they are followed or not? Many questions must be answered. The addition of a clause, in the contracts, saying that the company must follow the best software development practices is not enough. We must define such practices, establish a validation process and above all have an independent area or company with deep knowledge on the technological foundation that will be required, in order to inspect, measure and (in some cases) suggest changes for software or architecture improvement. Consequently, including in a supplier contract that the company’s methodology must be followed is not enough to obtain the desired quality. Some CIOs claim that they are already paying for a well-built software and it should be provided free of faults, with the use of best practices. However, independent inspection is crucial to assure that this is being actually done, and if not, to be able to use the product warranty still within the validity period – thus avoiding the undesirable rework and delay costs, which will be usually paid by the customer. Believing that the companies will deliver the software according to the standards and best practices is a mistake. Car drivers would not respect any traffic lights without an independent police work too. The earlier a noncompliance is detected in a software project, the lower will be the correction cost. Checking whether a software is fully functional only after delivery time is not an efficient practice. 140 120 100 80 60 40 20 0 R eq u C De T sig odin est ire n g me nt Pr od uc tio n along with customer dissatisfaction, and mainly some time after software deployment. With quality control, we can evaluate software suppliers and items, in order to achieve a predictable and efficient IT area. References CSC – 2003 IT Investment Study - Computer Science Corporation FITZGERALD, Brian. An Empirically-Grounded Framework for the Information Systems Development Process. Cork: ACM Electronic Library, 1997. ISO/IEC 12207 – Information Technology – Software Life Cycle Process – 1995 NSQE – SEGUE – National Quality Software Experiment ________________________________________ Luiz Wolf PMP, IT Management Master by PUC Campinas; TECH4B technology director Visit the site below to obtain other articles: www.tech4b.com.br Figure 4 – Fault correction cost x project phases – Source: NSQE-SEGUE Many times, the lack of software quality is felt only after some months, when the data volumes are higher, and faults, unavailability and response time issues start to impact the company business in an adverse way. If the overall cost of a software project (TCO) is computed, quality inspection becomes a vital factor to reduce such cost. Conclusion Only the implementation of a quality inspection process for the items created during the software development, maintenance and purchase processes can assure that the contracts are actually complied with and IT investments are effective and controlled – considering that the lack of software quality is the major cause of delays and cost increase in software projects,