0020b1aa.

doc

Gran Telescopio CANARIAS

TITLE

Quality Management in the GTC Project

Code : Issue : Date : No. of pages :

PUB/STMA/0020-L 1.A 27-04-98 9

Va Lctea, s/n - 38200 La Laguna (Tenerife) - SPAIN - Phone 34-922-315031 - Fax 34-922-315032 URL: http://www.gtc.iac.es E-Mail: gtc@iac.es

Prepared by

System Engineer Group

Signed in original

Authorized by

Pedro Alvarez Project Director

Signed in original Date: 11-05-98

Quality Management in the GTC Project

Fernando Manso Cullar GTC Project. Instituto de Astrofsica de Canarias (IAC) 38200 La Laguna (Tenerife) - SPAIN

ABSTRACT
The purpose of this paper is to describe the Quality System that has been implemented in the Gran Telescopio Canarias (GTC) Project to assure the quality of the GTC Telescope. This Project is a hightech scientific-engineering program and therefore it is important, as well as in other programs, that a common working methodology is set up among the participants. The vehicle used to meet this goal has been a Quality System consisting of the Quality Manual and the Operative Procedures. The first step in this effort has been to define what Quality is for the GTC. There are many definitions of Quality, and it was decide to adopt the following definition: uality is the fulfillment of the GTC requirements within the Project Schedule and Budget Q The present paper summarizes the process followed to set up the Quality System and the structure of this system, including the Quality Manual and the Operative Procedures. Keywords: Quality, management

INTRODUCTION
The aim of the GTC Project is to design, build and test a 10-m telescope, which will be installed at the Observatory of the Roque de los Muchachos (ORM), in the canary island of La Palma (Spain). This telescope will have a segmented primary mirror with an entrance pupil equivalent to a circular aperture of 10 m. in diameter. The conceptual design phase of the Project has been completed and at the present moment the preliminary design is being undertaken. First light is foreseen for the end of 2002. Beginning of the scientific operation is scheduled for the end of 2003. Quality has been introduced during this century in different disciplines, but it is nowadays when its application is becoming a major issue in, basically, every aspect of our lives: technical areas, medical services, transportation, education, etc. Quality is important in all these areas, but it is especially important in a high-tech development Project where the quality of the product is critical for the success of the program. In the GTC Project, Quality was identified as one of the main areas of the program and the System Engineering group was assigned to develop and set up an appropriate and useful methodology within the Project Office. The Quality definition for the GTC Project covers the three main dimensions of the program: technical, economical and temporal. The GTC Project members commitment to Quality will make us have the right telescope at the right time and within the planned budget. The first step was to develop a Quality Manual that expressed the policy to assure the Quality in all the Project disciplines and activities, and referenced the procedures that should be developed to dictate the common working rules of the Project Office.

Continuing with the process, the Operative Procedures that give the GTC Project members the detailed instructions to proceed in the critical activities of the program were developed. The last step was to close the Quality loop: it is necessary to establish a process to revise the Quality System periodically. This process will allow us to find out the current and potential flaws of the system. After its identification, corrective and preventive actions will be taken to avoid bureaucracy and non value added steps in the procedures. Quality Audits has been and will be run periodically to go over the Quality System and find ways to improve it with the support of all the Project Office members. Finally, the main lessons learned during this process are presented.

QUALITY SYSTEM DEVELOPMENT

The Quality System development followed the same process as any other engineering problem (Figure 1): 1. Set up the requirements for the Quality System. 2. Set up the constrains for the system. 3. Define the system alternatives. 4. Evaluate these alternatives. 5. Select and develop the optimal alternative. 6. Verify the requirements.

Quality System Requirements

Quality System Constrains

Quality System Alternatives

Alternatives evaluation

Quality System Development

Quality System Verification

Figure 1. Quality System Development Process

QUALITY SYSTEM REQUIREMENTS The first step to develop the Quality System was to define clearly its requirements. For the Project these requirements were: The Quality System shall define Quality for the GTC. The Quality System shall define the procedures to assure the Quality of the GTC.

 The Quality System shall be based on generally adopted Quality Standards. The Quality System shall avoid bureaucracy and non value added activities. The Quality System shall be developed with the support of all the GTC Project members. QUALITY SYSTEM CONSTRAINS The constrains were as important as the requirements to define the appropriate Quality System. The two main constrains were budget and schedule, but there were also other constrains that were taken into account. Some of them were identified at the beginning of the process, while others were found out during the process: There is a limited allocation of budget and human resources for the Quality System activities. There is a fixed schedule for the Project. There are many and varied opinions about Quality. There is a lack of Quality Culture. QUALITY SYSTEM ALTERNATIVES The three main alternatives considered for the system were: Quality Control System: A Quality System based on inspecting, testing and adopting the corrective actions. Quality Assurance System: A Quality System based on planned and systematic actions to provide adequate confidence that a product or service will satisfy given requirements for Quality. Total Quality Management System: A Quality System based on Quality centered management and the application of Total Quality Management tools.

ALTERNATIVES EVALUATION The evaluation of these three alternatives was done based on the requirements and constrains that had been previously set up. The Quality Control System was not considered appropriate for a Project with only one product: the GTC. We could not afford to wait until the inspection and testing phase to take corrective actions. The Total Quality Management required too many resources to be implemented and was not considered appropriate based on budget and schedule constrains. In a Project with only one product the effort required to implement this type of Quality System would not have paid back. The most adequate alternative was the Quality Assurance System, which would set up preventive actions in order to assure the quality of the GTC and reduce the risk of the Project.

QUALITY SYSTEM DEVELOPMENT The Quality System development phase started with the selection of a Quality Standard as a guide for the system. The most used Quality Standard for Quality Assurance is ISO 9001, so it was decided to use this Standard as the outline for the System. At this point the decision was made to adopt the structure suggested by this standard: the Quality System would be composed of: The Quality Manual that establishes the Quality policy of the Project and references the Operative Procedures. The Operative Procedures that dictate the instructions to implement this policy into the different activities of the Project. The following step was to identify which procedures should be developed to assure the Quality in the different Project areas of activities: Project Management. Quality System Control (Quality Audits). Document Control. Design Control.

Specifications Practices. Configuration Management System (SGC). Project Critical Reviews (PCR) and Project Progress Reviews (PPR).

Logistics Support. Supplier Control. Testing and inspection. Non-conformance Control. Packaging, Handling, Storage and Transportation. GTC integration and commissioning. These activities are integrated in the normal flow of the Project. A section is shown in Figure 2.

Project Management

Other Documents Configuration Changes SGC Docum. Control Configuration Changes SGC Docum. SGC SGC Control SGC Configuration Baseline A Docum. Control

Other Documents

Specifications & Drawings

Specifications & Drawings

Docum. SGC SGC Control Spec. Proc.

Project Reviews

Spec. Proc.

SGC Project Reviews

Configuration Baseline 0

Project Phase A
Insp.&Test. Proc. Supplier Control Inspection and Testing Supplier Control

PCR

Project Phase B
Insp.&Test. Proc. Supplier Control Inspection and Testing Supplier Control

PCR

Configuration Baseline B

SGC SGC Docum. Control Configuration Changes

SGC SGC Docum. Control Configuration Changes

Non-Conf. Control

Non-Conformance Control Evaluation & Selection Verification & Acceptance

Non-Conformance Control Evaluation & Selection Verification & Acceptance

RFPs Control

RFPs Control

Suppliers

Suppliers

Quality Audits

Figure 2. Project Flow section.

QUALITY SYSTEM VERIFICATION

The last phase of the Quality System development process will be the requirements verification. It has been decided to count with an external quality consultant to do this verification. This will add an external opinion that will help optimize the Quality System. QUALITY SYSTEM STRUCTURE
System Engineering is the group in charge of developing and establishing the Quality System, but all Project participants will be responsible for this system, working actively to improve it and thus meeting the GTC quality requirements. The Organization chart is shown in Figure 3. Although it is not common to have the Quality Assurance department under any engineering group, it was decided to have these activities included in the System Engineering group due to its deep involvement in the critical procedures development.

Project Director

Project Scientist

Project Manager

Administration Manager

System Engineering Group

Quality Assurance

Enclosure Group

Control Group

Telescope Group

Instrumentation Group

Optics Group

Figure 3. Organization chart

In the Quality System, the System Engineering group is responsible for: Development and maintenance of the Quality Manual and Operative Procedures. Quality Audits to revise the system and find ways to improve it. The following section will be dedicated to describe the Operative Procedures that have been developed to assure Quality in the Project areas of activities. This procedures are referenced in the Quality Manual and provide instructions to implement the Quality policy expressed in this manual.

GTC OPERATIVE PROCEDURES

This section presents, by areas of activities, short summaries of the Operative Procedures that have been developed. PROJECT MANAGEMENT The Project Management function is the most critical one for a high-tech Project with very tight budget and schedule. The Project will require the participation of a big number of entities and the development of new systems that will need to be well managed in order to be integrated into the GTC Project. Four aspects of this activity have been identified to be more critical: Schedule control. Budget control. Requirements control. Risk Management.

The first three aspects have been included in the Project Plan Control procedures. Every Work Package is evaluated in terms of objectives, cost and schedule and then incorporated into the Project Plan. The plan control is done, basically, by revising the goals of the Project weekly, analyzing the status of the Work Breakdown Structure (WBS) activities and foreseeing the potential deviations due to contingencies and changes in the schedule, budget and requirements. In addition, a Risk Management process has been implemented to be able to detect these contingencies and thus take preventive actions to avoid risks from different sources. This process has five steps: 1. Identify the potential risks. 2. Evaluate the probability and effects of these risks, assigning a rate to each risk. 3. Make decisions on which actions should be taken: actions to mitigate the risk probability or effects, actions to avoid the risk, or simply to assume the risk. 4. Document these results in the Risk Matrix. 5. Revise this matrix and repeat this process periodically. In the Project, each group has to develop its own Risk Matrix, being the Project Manager responsible for developing the Project Risk Matrix that includes those risks that either affect more than one group or whose effects are critical for the success of the Project. The groups celebrate Risk Management meetings monthly, while the Project Risk Management meetings are held every two months. After any of these meetings the corresponding Risk Matrix is updated and the actions incorporated into the group or Project plan. QUALITY SYSTEM CONTROL In this area, a Quality Audit procedure has been developed. These audits will be driven by System Engineering and they will be focused on finding: 1. existing and potential problems in the Quality System. 2. ways to improve the system. The audits will be run biannually and all Project members will take part in them. DOCUMENT CONTROL The Document Control Procedure includes the instructions to be followed in the Project for: Document identification, formats, revision, approval and authorization: The documents have to be produced with the Project templates and codes, and have to go through a revision-approval-authorization process to make sure the content is right. Document archiving: A physical and an electronic archive is kept with the documents produced and used in the Project. The electronic archive is available through the Project Office Intranet. Document distribution: each document has its own distribution list, so any revision of the document is communicated to the appropriate people.

DESIGN CONTROL The design activities are among the most critical areas of the Project. Three procedures have been developed to assure the Quality requirements in crucial steps of the design process: Specification Practices. Configuration Management System. Project Reviews.

Specification Practices
The main products of the design activities performed within the Project Office will be the Specifications that will play an important roll in the business process: they will be the main products of the Design phases and will be attached to the different contracts. A Specification Practices procedure has been developed to establish the guidelines for writing this documents. This procedure has been prepared following most of MIL-STD-961D and MIL-STD-490A recommendations.

Configuration Management System

Configuration Management is another crucial aspect of the design activities. There will be numerous companies and entities that will take part in the design activities and there will be a big number of subsystems that will be developed independently. This scenario requires a well thought Configuration Management System that will help us manage the different and numerous changes that will be implemented during the design, fabrication and installation phases of the Project. The Configuration Management System provides the instructions for: Configuration Identification: Unique and unambiguous identification of all subsystems and components and their related documentation has to be assured. A coding system for the Configuration Items and a Product Tree with these items have been developed. Configuration Control: A baseline system has been adopted to reflect the telescope configuration at any time during the Project. A new Configuration Baseline will be released after each Project phase. Between two different baselines, a Change Control system will assure that any change to the approved baseline is evaluated considering every implication in the Project. This evaluation is done by the Configuration Control Board, that also decides about the change approval. This method will help us make sure that all changes are communicated to the affected people and that the documentation reflects the GTC physical configuration. Configuration Information: The Configuration Information has to be controlled and reflect the GTC physical configuration. Configuration Audits: Configuration Audits will be driven to verify the GTC configuration.

10

Project Reviews
The Project Reviews are included in the verification and validation process for the GTC requirements. There are two different kinds of Project Reviews: Project Critical Reviews (PCR): The purpose of these reviews is to have the Project revised by a Project Review Board at the end of each Project phase and before going ahead with the next phase. Project Progress Reviews (PPR): These reviews will be held biannually to summarize the status of the Project. SUPPLIER CONTROL The Supplier Control has been normalized in a procedure that addresses the main steps of the process: Request for Proposal (RFP) preparation: Common guidelines have been established to prepare RFPs. Procurement Methods: The procurement methods will be: Simplified Acquisition Procedures, Sealed Bidding and Negotiation. Criteria have been set up to decide which method should be used based on budget, technical expertise and technical complexity. Supplier Evaluation and Selection: The evaluation and selection procedure will be based on setting an evaluation team that will have to select the most appropriate supplier in each case. Supplier Administration: Once the supplier has been selected, administration guidelines have been set up. These guidelines need to be customized for each contract, covering: progress reports, revisions, acceptance procedures, inspections and test, etc. LOGISTICS SUPPORT The support of the GTC telescope has been considered a major issue since the beginning of the Project. Within the Top Level requirements there are two that affect directly the GTC support and operation: High operational efficiency. High reliability. It was decided at the earliest stages of the Project to incorporate this two aspects (support and operations) into the design of the GTC telescope. The best approach was to follow the Integrated Logistics Support (ILS) methodology already implemented in other fields. OTHER AREAS There are other areas of activities where new procedures are being developed: Testing and Inspection: Common procedures will be set up to define tests and inspections instructions and result reports. Non-conformances: A procedure will set up the instructions to deal with non-conforming products and services. The procedure will address identification, segregation, evaluation and disposition of non-conformances. Packaging, Handling, Storage and Transportation: This aspect will be of major importance during the installation phase. Each subsystem and component design has to deal with this issues and determine the appropriate requirements.

11

 GTC integration and commissioning: Appropriate procedures will be developed to se up the guidelines to proceed with the integration and commissioning of the GTC. In the next months the Project guidelines for these activities will be set up, finishing with the development of the Quality System.

LESSONS LEARNED
The main lessons learned during the development of the Quality System are: Full commitment: The Project Office members full commitment to quality is essential to get benefits from the Quality System. Communication: Communication of Quality System objectives and progresses within the Project organization is important to get this commitment. Training: The establishment of new operative procedures need an extra effort in training the affected people. This effort has to be planned in advance. Timing: The Quality System has to be set up as early as possible in the Project. It is more difficult to change adopted habits than to start working with new procedures since the beginning. Bureaucracy and Overruling: Bureaucracy and overruling has to be avoided during the procedure development. The procedures have to streamline the processes and help the users, not make their work more difficult. Clear requirements and objectives: Before starting, clear requirements and objectives have to be set up. This will save useless work and reworks. Detailed Plan: A detailed plan has to be prepared at the beginning of the process, considering all the implications and resources needed.

12