4. SOME SPECIFIC ISSUES
General
There are some specific topics which tend to create problems for companies aiming for ISO 9001 certification. In this chapter I have collected discussions about some of these issues, although some of them have already touched on briefly in the previous chapters.
In many cases, these discussions arise from cases when the quality manager is unhappy when trying to make the company's software development conform to the requirements in ISO 9001. A typical lament may be: "I don't know how to handle cases, when I myself do not believe in a requirement in the standard. I don't feel sincere trying to enforce the requirement, when our software developers actually ought to work in another way." My reaction is always to ask for an example. Up till now, the examples I have been presented with, fall into two categories:
- The requirement is about records. Software developers often fail to see the usefulness of preparing and keeping records of reviews, tests etc.
- Literal conformance to the requirement would actually make the company a less competent supplier of software.
Regarding category 1, the problem is about understanding and accepting the need for records. This need stems from the fact that an activity must be auditable in order that conformace to ISO 9001 can be demonstrated. Also, of course, if an organization is to be able to improve, it has to record what is going on.
Category 2 problems have to do with misunderstandings about the scope and intention of ISO 9001. The TickIT guide, for example, stresses that the auditors shall be careful not to interpret the standard too literally. If a supplier does not conform to the letter of ISO 9001, this is no problem, if what the standard wants is achieved in another way.
Concurrent engineering
Formally, ISO 9001 requires that a specification be finalized and approved before use as basis for further work. This has been seen as a problem by some companies seeking ISO 9001 certification. These organizations try to shorten the calendar time needed for a project by running activities in parallel as much as possible. They want to do this, for example, by having programmers use specifications before they are finished, i.e. preliminary, non-approved versions.
The use of preliminary versions of specifications could probably be accepted by a competent auditor, but only if he or she can clearly see that the final work result will always conform to the final version of the specification. Also, the auditor would require records to be kept, so that any auditor can see that this has been the case for all projects.
One way to ensure that the final work result, e.g. a program, conforms to the final version of the specification used as a basis, is comprehensive reviewing. There should be a strict procedure so that when the specification is approved, the program is thoroughly reviewed and then updated to fulfill the approved version of the specification.
Working to a preliminary specification can sometimes be viewed as a preparation of the actual work. The programmer does not actually develop a program, he or she just prepares so that when the specification is finally approved, the programming can get a running start. However, if you use this reasoning, you can not refer to progress in programming until the specification is approved; if the specification work suddenly changes direction, all of your programs may become unsuitable.
Research departments
What if your company has long-term research activities going on, where software is developed, must the researchers also follow the strict model for software development? Many organizations have "lab"-activities, where ideas are tried before decisions about development of new products. Such activities frequently pose problems both for the company staff preparing certification and for inexperienced certification auditors, since the researchers usually refuse to follow the general development model for software.
The solution to this problem is to read the title of ISO 9001: "Model for xxxxxxx". Research is outside the scope of the standard. This means that the detailed requirements about design control, document control, testing etc do not apply to the research department. However, this is only true if the researchers do not develop products. If results from the research (specifications or source code) are used in a product, then we are talking development, not research.
The fact that the standard does not cover research may not be taken to mean that the research department can be ignored. If the certificate is to cover the whole company, also those activities outside the scope of ISO 9001 must be shown to be under control. The auditor would expect to find documentation of what the researchers are expected to produce, as well as records of reporting and follow up. If a researcher is completely free to choose his/her line of work, this should be documented.
Prototyping
Prototyping as part of requirements analysis
Some requirements are virtually impossible to specify without first trying. This is especially true about user interfaces. So often developers create throw-away software in the simplest possible way to try out what the requirements really should look like. The throw-away software is called a prototype. It is not developed in accordance with ISO 9001 requirements on design control etc.
As long as the prototype software is truly throw-away, this is no problem at all. Prototype development is information gathering, not product development. However, a not so uncommon case is when the sales manager happens to find the prototype. "Why, you already have it developed. It just needs some adjustments." Then the sales manager rushes away and promises immediate delivery to a customer. Now you have a problem.
If you sell a prototype, the ISO 9001 auditor will not be happy at all. This would mean that you deliver a product to your customer, which is not developed at all in accordance with your quality system, and such behaviour is judged very seriously by an auditor.
However, if you take great pains, it might be possible to convince the auditor that before delivery, the prototype is converted into a proper product. I don't know why you'd want to do this, since the conversion would cost more than to develop the product anew, using the information gathered from the prototype. You must have a procedure for this conversion operation, saying how it must be done. This procedure must prescribe that all documents required for a product must be prepared. Very comprehensive reviews must be conducted to ensure that the documents are correct
Prototyping as development method
Prototyping is sometimes used as a development method, especially in cases, when the end users find it difficult to explain what is required by the software. In one organization, the work method was described for me as follows. A requirements specification was written in very general terms on a high level. Thereafter the programmer would create a program after his/her own head, a prototype. The end user would then try to use the program and come back to the programmer with views on how the final program ought to behave. The programmer would modify the prototype and give it back to the user, who would test it again, etc. When at last, the user was satisfied with the program, the programmer would write a specification and the product was finished.
I find it very difficult to imagine how such a development method could be compliant with the design control requirements in ISO 9001. One possible way to look at the method is to see the programmer as a consultant, working in a project under the user's control. Still, it does not help very much.
If this is the way you want to develop software, and if your customers are happy with it, by all means do so, but do not seek ISO 9001 certification. Personally, though, I don't believe in development by prototyping. The result will be a program which has been changed again and again a large number of times, with no requirements and no reviewing of understandability and modifiability. There is no reason to believe that the after-the-fact specification will be accurate or sufficient for maintenance. Development by prototyping is a case of unmanaged software development.
Consultancy
Background
Consultancy companies often want to be software houses, running development projects of their own and taking responsibility for delivering a specific product to their customer. Because of this, they want to be certified to ISO 9001 in order to indicate this capability to prospective customers. A number of complications arise in such cases, and I will discuss them below.
Consultancy by supplying manpower
A company which only supplies manpower to the customers' projects can not be certified to ISO 9001. Such a company can not claim to have design as a part of its business scope. Its business is only supply. The consultants all work under the customers' quality systems for design. However, the company might become certified to ISO 9002, which is about "production, installation and servicing". This can create some frustration, since some mistakenly view ISO 9001 as the "highest" level of standard, and thus giving certificates higher value. Whether you are certified to ISO 9001, ISO 9002 or ISO 9003 has nothing to do with the "goodness" of your quality system. It only says what kind of operations your company perform. If you do production, ISO 9001 puts exactly the same requirements on your production process as does ISO 9002.
However, if the company were supplying some specific services, e.g. "Prestudies of the need for computer support in banking", it might be possible to achieve certification to ISO 9001. According to ISO 9001, a service is a product. If the company designs and produces services, it might be able to show conformance to the requirements in ISO 9001, e.g. regarding design control. Still, such a certificate would not indicate that the company's ability to design and produce software has been certified. Each ISO 9001 certificate includes a text about its scope, i.e. what business areas and activities the certificate covers.
Using the customer's quality system
The fact that a consultancy company uses the customer's quality systems does not in itself preclude certification to ISO 9001. The standard does not require that a company itself invent all its quality system. The company may even have several different quality systems to use in different kinds of projects. If a company only uses the quality systems of its customers, the following conditions ought to be fulfilled in order for the company to achieve ISO 9001 certification:
- The company shall itself take reponsibility for development projects, and this shall be clear in the contract with the customer.
- What parts of the customer quality system applies to the company shall be clearly stated in the contract.
- The rest of the quality system needed for the company must exist, be in operation and fulfill ISO 9001.
- The internal quality audits of the company shall cover all activities conducted under the customer's qualiy system.
- The internal quality audits of the company shall cover all parts of the customer's quality system used by the company.
- There shall be a mechanism for the company to require and achieve corrective actions regarding the parts of the customer's quality system used by the company.
- In all cases when the company uses a customer's quality system, this shall fulfill the requirements of ISO 9001. This shall be clearly stated in the contract with the customer.
Mixtures of consultancy and development
Some companies have in their business both pure consultancy and development. In order to become certified to ISO 9001, they have to show that both the supply of consultants and the development is under proper control and meet ISO 9001 requirements.
Let's say that one such company has received a certificate to ISO 9001, which covers consultancy as well as development of software. Let us further assume that this company supplies a customer with a project manager for a software development project. The project manager is a consultant, and works in accordance with the customer's quality system, which is almost nonexistent. Because of this lack of a proper quality system, the project fails in a spectacular way, and the customer complains in the trade press: "The project was a failure because of our consultant project manager from XYZ-soft. And these guys have been certified to ISO 9001 by QPL-cert Inc!"
This situation could be extremely damaging for the certification body in question. By issuing the certificate, QPL-cert has vouched for the capability of XYZ-soft, and for a certification body, its reputation is its main asset. For this reason, if you want to have both development and consultancy in the scope of your certificate, the certification body will probably require you to undertake consultancy only in cases where a proper quality system is in operation. How this requirement should be formulated may be a matter of debate, but it does not seem reasonable to require you to only do consultancy for customers holding an ISO 9001 certificate.
Old software products
Often, a supplier will introduce a number of new rules and standards for software development as a part of the process of achieving compliance with ISO 9001. Usually, the supplier maintains a considerable amount of old software, which was developed according earlier rules (or none at all). Sometimes the maintenance and enhancement of old software is a major part of the supplier's business.
I sometimes get the question "Do we have to rewrite all the old software to fit our new rules and standard?" Fortunately, the answer is no. Otherwise ISO 9001 would be unachievable for a large part of the software industry. However, in order to meet ISO 9001, the supplier must show that the maintenance of old software is under proper control.
Proper control might, for example, be a documented procedure for enhancement and error correction in old software. This procedure would identify the following:
- What software products are covered by the procedure
- Responsibilities and authorities regarding this maintenance
- A procedure for error reporting and change request
- A procedure for configuration management for the old software
- Rules regarding documentation of changes in old software
- Rules regarding review and testing of changed software
Of course, some of the procedures and/or rules identified in the procedure for maintenance of old software may be the same as are used for new software.
Customer training
Customer training is an important part of some software businesses. In the context of ISO 9001, this is a service, and a service is a kind of product. How to apply the requirements of the standard to a large extent depends on the specific type of customer training undertaken. An auditor would expect to find for example the following:
- Documented responsibilities and authorities for the development of courses and course material
- Procedures for development and maintenance of courses
- Procedures for configuration management of course material
- Agreements with customers, which clearly cescribes the training to be delivered
- A method for obtaining feedback on customer satisfaction with the training.
ISO 9004-2 gives further advice on quality systems for services.