Quality assurance

Quality of project work and project management

Hans Mikkelsen

Is quality management a discipline in project manage- ment or vice versa? Is quality assurance just extended use ofbureaucraticcontrolmethodsadoptedfromproduction quality control? This paper stresses the need for better integration of quality management activities into the activities of professional project management. Further, it raises the question of effective quality management tools in the early project phases, where requirement specifica- tions and conceptual design are made.

Keywords: quality, quality assurance, organization, quality management.

CONCEPT OF QUALITY

The concepts of quality and quality management are perceived in several different ways (see Figure 1). The classic perception of quality is the position of a product property on a good-bad scale - e.g. the quality of a given surface protection. However, quality is also whether a property exists or not - e.g. whether there is any surface protection at all. In addition, quality is also the existence - or not - of product functions. The concept of quality and quality parameters depend on the object to which quality relates. Everything has a quality, so it is hardly surprising that quality manage- ment can sometimes be all-embracing and superior to all other forms of management. In this paper, quality management will be treated as one of the management functions in the entire project management.

QUALITY-MANAGEMENT ARENA

The word ‘quality’ is immediately associated with ‘quality for the customer/user’. However, every

Sant and Bendix, Skovlytoften 9B, DK-2840 Holte, Denmark

l Quality is style. Quality is a property that can be felt and experienced without one always being able to define it.

l Quality is ‘more of the good things’. Quality is product-oriented. The greater the quantiD/ of a desired property, the better the quality will be, and the greater the value. A Rolls-Royce is better than a VW.

l Quality is fulfilling the customer’s needs/requirements. Quality is user-oriented and an expression of the product’s usefulness, seen from the user’s point of view. Usefulness means meeting the user’s needs and the product reliability, safety, durability, etc.

l Quality is ‘value for money’. Quality is a marketing-oriented expression. High quality is maximum usefulness for least money.

l Quality is keeping one’s word. Quality is a production-oriented expression. Quality is meeting the specified requirements.

l Quality is ‘no defects’. Quality is both a user-oriented and a production- oriented expression. The goal is non-defective and reliable processes and products.

Figure 1. Definitions of quality

interested party in a project and its product has a perception of quality - in the interested party’s spheres of interest. To create quality is thus to consider and balance several interests, including those of the project participants themselves.

Quality relates not only to the product, but also to the instructions for its use, to installation, to service, to marketing, etc. A holistic approach is essential.

The picture of the customer’s (user’s) needs and requirements/expectations concerning quality is drawn by ‘observers’ and ‘interpreters’ and is communicated to the designers through many levels. It is important that the designers themselves experience the customer’s situation.

A project product is created through a process with several work phases (see Figure 2). Operational handling

138 0263-7863/90/030138-06 @ 1990 Butterworth-Heinemann Ltd Project Management

Quality assurance

-L

:I- Quality in use

Figure 2. Quality pathway

of quality demands that the quality is defined and created in all the ‘intermediate products’ on the way to the end product and its use.

There are many players in a project. Very often, the people who define quality and plan quality do not experience the final product quality. They plan in other people’s spheres. Quality can seldom be measured when it is designed. In the engineering phase, it is difficult to appreciate fully the relationship between design decisions and consequence. Gaining experience in quality calls for organizational integration in the project work.

Project work often means development work. New ground is being broken, and too little is known to be able to act and choose with certainty. Quality cannot be incorporated directly, but choices must be made and then later tests and checks carried out to see that the quality is right.

The feedback time is long. Months or years can pass between an engineering action (e.g. a designer’s choice of component) and ascertainment of quality at the user’s premises (after use for some time). And in the meantime, disturbing reports may have come from other parties involved (e.g. the purchase and production departments) about other quality aspects.

When products are designed, quality is an either/or phenomenon (good/not good). In production and use, quality becomes a statistical phenomenon, with variations determined by stability in processes and surroundings. The product as a whole is complicated and has many different aspects. How can we encompass them all, take all the considerations, handle all the relationships, foresee the consequences?

There is a real, measurable and ascertainable quality, and much effort is expended on specifying and measuring it. However, there is also the quality that is

experienced - and that quality is influenced by the way the product is presented and by the image of the product and the company. How does one formulate targets for experienced quality?

Specifications give a feeling of confidence, but it can be a false feeling. It is good project practice to formulate ‘clear goals’ and draw up strict and unambiguous specifications. However, that does not necessarily mean that the product fulfils the user’s need.

MISCONCEPTIONS OVER COST

It is considered by some that it costs more to create quality, and it has been said that ‘We can afford to correct errors but can apparently not afford to avoid them.’ The total cost of quality consists of two parts: the cost of preventive activities and the cost of errors.

The cost of errors is partly internal, e.g. the cost of corrections and of rejections, and partly external, e.g. ruined reputation and loss of sales. Some of the costs are paid by the user. One of quality mangement’s tasks is to make the cost of errors visible.

The cost of prevention is often regarded as quality control, inspections and reviews, with the involvement of quality control personnel. However, prevention is, of course, also a vital aspect of design, engineering and production planning - in brief, the technical project work. Here are far greater opportunities for influencing quality than through the inspections. Here, it really should cost nothing to get things right in the first place.

MANAGEMENT OF QUALITY

Looking at the many campaigns and efforts for quality management, some characteristic features can be found.

First, there is the ‘bureaucratic model’, in which

Vol 8 No 3 August 1990 139

Quality assurance

Input

Materials/ information

/’

‘._-I

Figure 3. Quality management actions

f---y ,._\,\~

1 Configuration management

Product ‘;;\ \, economy

\ \

(Functions, systems, (Operations/application )

!

Figure 4. Elements of product management

quality is achieved through planning, specifying, reviews, inspection and documentation. It has compre- hensive procedures and quality management manuals, and a quality assurance organization with a quality

Execution

manager referring directly to the top management. Second, there is the ‘motivating model’, where

quality is achieved by the project workers creating it ‘at the first stroke’. They must be motivated to want quality; they must be informed so that they have a holistic understanding of the project and see and understand the user’s needs. Then they can make reasonable decisions.

A third characteristic is that the quality control activities are not performed only in the production phase. They are also displayed in the design phase, but perhaps very much influenced by methods and ideas adopted from the production phase (see Figure 3).

In addition to the technical tools and methods used in creating the project product, there are some general methods of managing product functions, structure and economy (see Figure 4):

l requirement analysis, market survey; l financial analysis and design; 0 system engineering, where the product and its

surroundings are perceived and described as a set of related systems;

l modelling methods, creating the product structure; l configuration management, which ensures that chosen

functions, systems and structures (components) are maintained and are changed only after thorough consideration;

140 Project Management

methods of estimating future production, service and operating costs; value analysis, which is intended to maximize the application value in relation to costs; design to cost, which is intended to ensure that the choice of design is kept within the target product cost. In project management, it is worth noting that one has to keep control of two ‘economies’ - the project economy and the product economy.

A number of general methods are available specifically for managing quality:

l the phased project life cycle, in which the decision points between the phases encompass a comparison between the actual product model and the formulated targets/requirements, a re-evaluation of targets/ requirements and thus an assessment of the relevance of the actual solution, and a formulation of the basis and targets for the work in the next project phase;

l reviews and audits of targets, design proposals, engineering solutions, production methods, etc;

l the quality activity programme, comprising the special actions to be carried out in order to create the quality; typical actions are: specification, monitoring, inspection, review, testing, etc; the programme is partly based upon:

description of success criteria; drawing attention to the quality factors regarded as most important to gain a good product reputation; analysis of uncertainty and risk (FMEA analyses, etc); attention is drawn to what is regarded as difficult; here, the quality management borders on risk management, another area of topical interest to project managers; a number of branch-specific methods for specifying and measuring quality; use of codes and standards.

Reviews have come to be regarded as a broadly applicable method of achieving quality. However, there may be reason to warn against uncritical use of the method. If a review is performed by an outsider who does not know the project’s goals and situation in depth, who is not enthusiastic about the project, who regards the review as a secondary job, and who receives too little information on which to base it, then the review is more likely to be counterproductive.

An important problem is: How does one create/ achieve quality in formulating the requirements and in the initial design process, when the big decisions about the product concept, the technology, the product’s systems and structure are made? Are there any good tools that may be used for quality management in these phases of the project?

The requirement specification is often emphasized as the tool for clear, unambiguous formulation of goals for the design/development work. It is perhaps a poor tool, because it says too much about the product design.

Vol 8 No 3 August 1990

With the

Quality assurance

requirement specification, the design work . _ has already begun. Specification ot requirements and specification of needs are not the same thing. Instead of a requirement specification, it might perhaps be better to start by describing the anticipated user situation - in other words to specify needs. Then requirement specifications and product specifications are prepared at each phase of the development process.

Another tool is the project start-up seminar, the aim of which is to create a common conception of goals among the project participants and to establish a basis for good communication. The pitfall here is that this is all based on the already formulated goals and frame- work - without ever taking a critical look at those goals and framework. It is a project’s birth process and the very early decisions that make or break its quality. Delimitation of the project and its product is another critical area.

One of the most challenging tasks in creating product quality through the project work is to establish effective communication among the project participants. The word ‘effective’ is used here in its widest sense. The user’s need is not the product, as such, but what the product does for the user and the way it does it. Is that need perceived, understood and described at the very start of the project - or is it gradually appreciated as the product develops? Does the designer see needs before the user sees them? Scenario methods and other forms of depiction and modelling are perhaps essential communication tools.

Suggested ideas or proposals are subject to conse- quential analysis. How do we assess the consequences of an idea or a sketch? Consequential analysis is based on experience and testing. Here, too, depictions and prototypes are perhaps the essential tool.

The design task is a complex one. It involves many elements/components and many requirements/ considerations/relationships. How does the individual designer get hold of the relevant requirements? Recently, one method, Quality Function Deployment (QFD) has attracted attention. This is a method of ‘translating’ needs/requirements into quality parameters and linking these parameters to various elements of the product. However, this does not solve the problem because some requirements are perhaps only recognized the moment the designer sees or presents a possible solution.

Quality is created by using experience. Some of the above-mentioned problems have to be solved in the way the project is organized (see Figure 5). Choosing the qualified project engineers (rather than placing them in the steering committee, as reviewers or as advisers), extensive communication, continuity in the staffing of the project, conscious and organized learning as the project proceeds, are some of the answers. The project team should be made into a ‘quality circle’.

Learning may, for example, be based on two questions: What worked well - and why? What could have been done better - and how? Another approach is to list problems and errors in the project and ask:

141

Quality assurance

l When was the problem discovered? l When could it have been discovered? l When was the problem created?

CONCLUSIONS

Quality management is one of the management func- tions in a project, and must be carried out in parallel with other management functions (see Figure 6). Special control activities directed towards creating quality should probably be used (see Figure 7). These

l Knowledge, expertise and know-how

0 staffing 0 continuity 0 learning

l Attitude and conduct

0 we are going to win

0 Communication

o holistic perception o understanding of relationships 0 visualization

Figure 5. Organization for quality

l Project task l Project product

0 Configuration o Quality o Economy

l Technical documentation

l Surroundings l System adaptation l Market adaptation

l Interested parties l Communication with interested parties

l Resources 0 Personnel, equipment l Materials and components 0 Project economy

l Procedure/course of action 0 Project contract 0 Project structure l Process and work methods l Time and activity management 0 Project organization 0 Communication

Figure 6. Management functions

Quality assurance

- requirements concerning QM J - create confidence that the product/service

will satisfy the quality requirements

Quality management I

- determination of QUALITY POLICY AND AIMS! - use of QUALITY MANAGEMENT SYSTEM

Quality control

- QUALITY ACTIVITY PROGRAMME - preventive activities, specification - rnspection - audit - handling of errors/deviations - documentation

A- ~ Qualitv audit systematic, independent examination is the quality management system good enough? does the quality management system work satisfactorily?

Figure 7. Special control activities

142 Project Management

Quality assurance

l Quality is related to situations rather than technical data.

l Most qualities are obligatory properties, although a few are positioning properties.

l The professional project worker has his own motiva- tion - only the amateur needs motivating.

l It is professional to be uncertain. l Interest in quality is greatest when writing the basic

specification and when the product is a reality. l The biggest mistakes are made at the beginning of a

project - and are unfortunately not discovered until the end of it.

l Requirements specification is not the same as the specification of needs.

l Users’ wishes do not always express their needs. l The specification of requirements is the result of a

power game. l The specification of requirements never covers every-

thing it should. l Solutions create cognition - and new requirements. l The most difficult project problems are communication

and imagination. l People - not machines - make the errors. l Like master, like servant - the project manager’s

visible interest in quality is the driving force. 0 It takes discipline to achieve quantity. It takes culture to

achieve quality!

Figure 8. Statements concerning the creation of quality

activities are concerned partly with the project product and party with the project process.

However, quality management must be integrated with project management - not solely the remit of a separate quality organization, nor with separate manuals and procedures. The most vital means of creating quality lie in professional project management and professional project work.

In this professional project work, the development of methods and tools that assist with the creation of quality right from the start of the project - in the decision on its limits, understanding of needs and design of a viable product concept - must be continued.

BIBLIOGRAPHY

Hein, L and Andreasen, M Intergreret (Integrated Product Development

‘roduktudvikling Federation of

Danish Mechanical, Engineering and Metalworking Industries, Denmark (1985) (in Danish)

Mikkelsen, H, Andreasen, M and Hein, L Risikohdnd- tering i Produktudvikling (Risk Management in Product Development) IPU/Konstruktionsteknik, Denmark (1989) (in Danish)

Mikkelsen, H and Riis, J 0 Grundbog i Projektledelse (The Fundamentals of Project Management) Prodevo ApS, Demark (1989) (in Danish)

Hauser, J R and Clawing, D ‘The house of quality (the QFD-method)’ Harvard Bus. Rev. (May-June 1988.)

Hans Mikkelsen gained his MSc in production management from the Technical University of Denmark. He has worked in production management covering most aspects in that area. Since 1970, he has furthermore been engaged in product management in several types of projects and branches, working as a management consult- ant. Over a number of years, he has been involved actively with Danish project management societies, and has taken a particular interest in project management training.

Vol 8 No 3 August 1990 143