Chapter Quality

Inherent in the project design, as well as the product design, we must find quality. Everyone on the team must contribute to producing quality results. Engineering will often be the lead for the quality planning and implementation, and of course the PM has the overall accountability for quality.

There are three processes associated with quality - quality planning, quality assurance and quality control.

Quality Planning is identifying which quality standards are relevant to the project and determining how to satisfy them. Quality Assurance is the evaluation of overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. Quality Control is defined as the monitoring of specific project results to determine if they comply with relevant quality standards, and identifying ways to eliminate causes of unsatisfactory performance. Lastly, Quality Management is determining and implementing the quality policy.

If the customer defines the expectations, and the team gets agreement on these, this sets the quality standards. But if the team sets the standards, and the customer doesn't agree, it doesn't matter how well the product meets the standards, the client will not be happy. So it is crucial that there be early agreement on the standards. It is recommended that this agreement occur before the project parameters are set. Otherwise the team may not have the right type and amount of resources to meet the quality requirements: a set up for failure. It is the responsibility of the PM to ensure that there is full buy-in to the standards at a detailed level, then to manage the expectations as well as the project.

Since quality standards have to be set, these must be communicated, agreement must be reached, work must be monitored, and continued communication is required, it is obvious that there is a cost to producing quality. This cost includes not only the cost of the work mentioned, but also any cost that is incurred to meet the standards that are set. This cost can be considerable. On the other hand, what is the cost of not meeting agreed upon standards? Possibly dissatisfaction with the whole project, which might have consequences like non-payment for the work, non-acceptance without significant rework, loss of future business, difficult working environments if there is future business with the customer.

Who is the customer? In some projects the answer to this question is obvious. The project is in place to satisfy an external client or set of clients. In other cases, the project deliverable might be going to someone internal. There is always a customer, and this is the person or group whose expectations need to be met.

Most quality programs were put into place for corporations rather than for projects, but the principles apply well to projects in most cases. Let's look at a few of these programs.


W. Edwards Deming was one of the world's leading experts in quality management. He gave 14 points which will lead to quality management.

Deming's 14 Points for Quality Management

■ Create constancy of purpose for improvement of product and service.

H Adopt the new philosophy

M Cease dependence on inspection to achieve quality.

H End the practice of awarding business on the basis of price tag along. Instead, minimize total cost by working with a single supplier.

■ Improve constantly and forever every process for planning, production and service.

B Institute training on the job.

• Adopt and institute leadership. Drive out fear.

Figure 2

Another quality guru, Joseph M. Juran recommends 10 steps to producing quality, which look at the issue differently.

Break down barriers between staff areas. Eliminate slogans, exhortations, and targets for the workforce Eliminate numerical quota for the workforce and numerical goals for management. Remove barriers that rob people of workmanship. Eliminate that annual rating or merit system. Institute a vigorous program of education and self-improvement for everyone.

Put everybody in the company to work to accomplish the transformation.

Juran's 10 Steps to Quality Improvement

Build awareness of the need and opportunity for improvement Set goals for improvement Organize to reach the goal (establish a quality council, identify problems, select projects, appoint teams, designate facilitators). Provide training

Carry oat projects to solve problems Report progress. Give recognition, Communicate results. Keep score.

Maintain momentum by making annual improvements part of the regular systems and processes of the company.

Figure 3

Crosby suggests 14 steps which are slightly different.

■Make it clear that management is committed to quality.

■Form quality improvement teams with representative« from each department

■Determine where current and potential quality problems lie.

■Evaluate the cost of quality and explain its use as a management too.

■Raise the quality awareness and personal concern of all employees.

■Take actions to correct problems identified through previous steps.

■Establish a committee for the zero-defects program.

■Train supervisors to actively carry out their part of the quality improvement program.

■Hold a "zero-defects day" to let alt employees realize there has been a change.

■Encourage individuals to establish improvement goals for themselves and their groups.

■Encourage employees to communicate to management the obstacles they face in attaining their improvement goals.

■Recognize and appreciate those who participate.

■Establish quality councils to communicate on a regular basis.

■Do it all over again to emphasize that the quality improvement program never ends.

Figure 4

Common threads can be seen through all of these approaches. These are:

demonstrate the management commitment to quality involve all employees in the production of the quality measure the quality of the results reward the desired behaviours

However, Deming does also say that quality is a management responsibility. Poor employees do not produce poor quality - poor management does. So management cannot pass off the responsibility to anyone. In the case of projects, this makes the PM accountable overall for the quality of the deliverables.

In Project Management A Systems Approach to Planning, Scheduling and Controlling," Harold Kerzner provides some good insights into the problem of quality management and some suggestions for success in this area. His observations span a wide range of potential actions and they are quite consistent with the principles espoused by the gurus. Kerzner says that quality is everyone's responsibility, including white-collar workers, the indirect labor force, and the overhead staff. Defects should be highlighted and brought to the surface for corrective action. Quality problems lead to cooperative solutions. Documentation of "lessons learned" is essential so that mistakes are not repeated. Improved quality saves money and increases business. Quality is customer focused. People want to produce quality products do so. Quality occurs at project initiation and must be planned for within the project. Let's analyze this further, since there is so much information packed into these few sentences.

Quality is everyone's responsibility. This is consistent with what has already been said, but this takes it further. When work is done, everyone who has an impact, even an indirect impact, contributes to the quality of the results. This means that the project team needs to ensure that all project participants are aware of the quality standards, and are willing to contribute to meeting them. And this might necessitate having to compensate for some outside influences, if these influences cannot be brought into line with the project quality standards.

Defects should be highlighted and brought to the surface for corrective action. We should ensure that we evaluate project deliverable results, to ensure that these meet the standards. If we find that something falls short, in spite of the other project pressures, we need to take corrective action, in order not to risk producing unacceptable results later.

Quality problems require cooperative solutions. The team needs to work together to solve quality problems. Problems may occur within the responsibility area of one individual, and sometimes this person can implement the correction, but in many cases the problems exist because of the influences impacting the person or group not meeting the standards, and this brings out the need for cooperative action to reach the desired results. People generally do not produce poor quality work because they want to, or don't care. The cause is usually related to influences from others.

Documentation of "lessons learned" is essential so that mistakes are not repeated. Documenting lessons learned is a technique used in project management to benefit from any mistakes that have already been made. When people take risk, there is a potential for mistakes. In projects there is a need to take risks, since projects produce change. Therefore there will be some mistakes. The idea is that we need to learn from these mistakes, as opposed to blaming and punishing the people who make them. If people are placed in positions where mistakes are certain to happen, it is only professional to tolerate some mistakes, as long as the people involved acted to the best of their ability. However, it is not wise to make these same mistakes again. To prevent this, we need to document them, make the potential known, and ensure that people working in similar situations in the future will be forewarned not to make the same mistake again. This requires maturity on the part of the overall management involved. If this is not yet there, the project teams will have to work to educate the company about the value of these principles.

Improved quality saves money and increases business. This was discussed above. Just as poor quality can lose business, better quality can attract new or additional business, this leveraging the return on the investment in planning and producing it.

Quality is customer focused. There is no point in producing something that does not meet the customer requirements. Not so obviously, producing something that is much better than the customer needs may also create a negative reaction, if the customer thinks that he is paying extra for something he does not want.

People want to produce quality products. This implies that management should take a positive view of the intentions of the employees and the project teams. If poor results have been obtained in the past, look for a cause other than poor motivation on the part of the workers. People do want to do a good job, and will do so, unless some influences make this too difficult for them.

Quality occurs at project initiation and must be planned for within the project. As discussed, we need to set our standards early, before the work begins, and then engineer the project to ensure that the resources are in place to allow the appropriate quality to be produced.

Kerzner also outlines the factors which affect quality, and these should be kept in mind as project planning proceeds. They are generally related to the product that the project is producing.

■ Salability: the balance between quality and cost

■ Produce-ability: the ability to produce the product with available technology and workers, and at an acceptable cost

■ Social acceptability" the degree of conflict between the product or process and the values of society (i.e., safety, environment)

■ Operability: The degree to which a product can be operated safely Availability: the probability that the product, when used under given conditions, will perform satisfactorily when called upon

■ Reliability: The probability of the product performing without failure under given conditions and for a set period of time.

Quality requirements can be actively expressed, but sometimes they are only implicit. In fact, included in every project there will be some standards that are implied. It is not always possible to state everything explicitly, yet people have a right to expect certain standards will be met. To give a simple non-project example, let's consider a recent experience. While traveling in Europe, staying in hotels that were not modern, and also not cheap, a group of North American professionals began to wonder whether they should have specified that they wanted a bed when they booked a hotel room. Each new room was different from the last, but each time many of the things the people were used to getting in a hotel room were missing - things like note paper, shampoo, a bathtub. And whenever they asked about the things they wanted, the general reaction was "Oh. You wanted that. Well, we could have provided it, if you had requested it with your booking. While these things were included as basic in the minds of the travelers, they were not basic in the minds of the hoteliers. Hence the need to define the requirements, and the level of quality. The bed, fortunately, seemed to be considered an implicit requirement by all parties. The more clearly the standards are defined, the higher the probability that they will be met.

Of course, the customer sets the expectation levels - but if the customer is not able to clearly state what he is looking for, the project team must work with him to ensure that there are commonly understood specifications. For example, suppose you are designing a new electronic service to be offered publicly. How can you determine the specifications, so you can design something that you are quite certain will be attractive to all stakeholders, especially customers? The requirements can probably be determined from market studies. To determine the quality standards it will often be necessary to hold focus group discussions, or even better, to build a sample or simulation of the proposed service, and run a trial. However, just building the prototype can be quite expensive and time consuming, so there could be a high cost to just obtaining the right quality standards.

Quality specs need to be stated in such a way that common understanding will occur. This might mean including diagrams, or referencing standards, or just clearly specifying what is expected, and how this would be measured. They should be specific enough that they can be measured.

For projects and products which have high yield outputs - i.e.. Many boxes, many screens, many response times - statistical analysis techniques can be used to determine the extent to which quality standards are being met. We will mention a few ofthese within this chapter. For projects without high volumes, quality must be determined by direct comparison to defined and agreed to expectations.

Statistics might also be employed to measure the quality of the product. In a production environment, with products produced in high quantities, sampling is often used to measure the quality of the product. In a telecom service, samples or full statistics can be used to measure items such as response time, call answer time or MTTR. In manufacturing, products from assembly lines can be evaluated. In the upcoming discussions, it is assumed that the reader has a basic understanding of statistical terms such as probability distribution, mean, standard deviation, and variance.

Some statistical techniques that might be used in the determination of quality are:

■ benchmarking

■ Pareto Charts cause and effect diagrams histograms statistical process control

Benchmarking is frequently used in the definition of telecom services. Here benchmarking is the comparison of the a new service to one which already exists, where both are probably targeted towards the same market segment, and the existing service is known to be successful, to determine the best service characteristics to include in the service under development. Similarly, in projects, people often study another project with similar objectives or product components to determine the best processes to use on their project to ensure quality results.

Pareto was an Italian economist who studied ways to improve life for people in Italy. He originated the well-known 80/20 rule, which today is widely applied to issues in almost every area. His premise was that 20% of the people will always make 80% of the money. Therefore improving the lot of the poorest people will only cause a shift in the balance, or a raising of the overall curve, because after the change, 20% of the people will still have 80% of the money. This is widely applied in telecommunications. 20% of the trouble calls take 80% of the effort to resolve. 80% of the revenue comes from 20% of the customers. Etc. The Pareto rule can be modified to predict that 80% of all problems are caused by 20% of the causes. We can use this technique to help in solving problems.

For example, suppose that following the installation of new fiber facilities throughout three major cities, a number of troubles have been found. Some troubles occur in each city, and others (most) occur in only one location. In testing the facilities, the technicians have identified about 15 different problems which they have listed. A summary of the lists can be created. The technicians now need to locate and fix all of the problems, but finding and fixing all of the problems will take quite a lot of manpower and time. The first step in the Pareto analysis would be to create the summary list identifying the problems and the frequency of occurrence of each. Then to maximize the return on the effort, for those two (or other meaningful number) problems which occurred most frequently, estimate potential causes. The list of causes of each problem can also be summarized, and the probability that each would be the cause can be estimated. This then gives the technicians a basis for selecting the approaches which are most likely to yield the desired return in the shortest time. In fact, in real life, many telco technicians do this automatically, without taking the trouble to make the lists and show the numbers. But the process is applied nevertheless. On projects, the documentation of such processes can be kept to show what certain paths were taken over others.

Using the cause and effect technique, the analyst uses a systematic methodology to analyze the cause of each major defect, then determines corrective actions for the most significant causes. In the case of the fiber installation above, he could look for causes that fall into various categories, such as those that are due to human error, are due to measurement error, are due to equipment failure, or time of day, or installation methodology, or even the environment - say water in the ducts.

Histograms can be used to illustrate the relative frequency of problems, and to decide which to tackle for the best return. For example, Figure 5 shows the problems that occur in the use of a web site. We can quickly see that we might first want to tackle the entry of the payment information, first because it has the highest frequency of occurrence, and also because there is a high impact if people cannot pay properly. The team needs to brainstorm possible causes, and investigate those that are most likely, in order to fix this problem with the least loss of time and effort.


Our website offers visitors the opportunity to purchase a variety of phone sets, mobile phones pagers, and answering devices. Problems reported by people using the site are logged. Some sample results show:

Figure 5

Statistical process control is the comparison of values obtained by sampling to pre-established control values, in order to determine when action needs to be taken to meet the set standards. The goal is to produce a service or a product that conforms to design specs or, in the case of projects, to use processes that allow the project management to produce the results required. The process is as follows:

1. Select a parameter to be measured (i.e. call answer time, number of billing errors, computer response time, download time etc).

2. Set the desired (mean) value for the parameter.

3. Set upper and lower control limits (range within which values are acceptable).

4. Determine % of values which can tolerably fall outside the control limits (control limits should be tighter than specification values).

5. Sample.

6. Take action as appropriate when "too many" values fall outside the required range.

Examples of control and specification limits are shown in Figure 6 above.

Many companies have elected to impose rules that define the proportion of production that they will tolerate falling outside of the specification limits. For example, operating companies specify for internal measurement purposes that 99.999% of the time the network will be available for calls. This means if we were to check all call attempts made, no more than .01% will have failed to connect due to a network failure. Note that this specification typically refers to network failures only, not call failures due to overloading of capacity.

If this stringent specification is to be met, the telephone company cannot wait until it starts seeing a .01% call failure rate before taking action. Obviously at this point, the specs are not being met, and further failed call attempts will no doubt occur while the telco analyzes and fixes the problem. To head this off a control level must be set which is stricter than the desired success rate, sufficiently more rigorous to allow the telco time to resolve the problem.

The most common techniques used are called 3a and 6a, representing failure rates that are represented by three and six standard deviations from the mean in a normal distribution. In a 3a standard, we specify that the upper and lower specification limits are ±_ 3a, in a 6a standard, correspondingly at ±_6a.

In a normal distribution, the percentage of values falling within the acceptable range is shown for 1, 2, and 3a thresholds. At 6a, this rises to 99.999%, a stringent requirement indeed!

Standard Deviation &-9974%->


^■»s-^ t

■3a -2a -la M la 2a 3a

Figure 7

There are many quality programs such as TQM and the ISO standards. Each has it's own criteria and methodology for ensuring quality. If one such technique is used by the company, this one should also be used by the project. Using one of these techniques for a project only, rather than corporately would probably create too much overhead for a project. But some technique should be used on every project to control quality. As one illustration, let's look at the TQM process. The steps are:

■ Solicit ideas for improvement from employees.

■ Encourage and develop teams to identify and solve problems.

■ Encourage team development for performing operations and service activities resulting in participating leadership.

■ Benchmark every major activity in the organization to ensure that it is done in the most efficient way.

■ Utilize process management techniques to improve customer service and reduce cycle time.

■ Develop and train customer staff to be entrepreneurial and innovative in order to find ways to improve customer service.

■ Implement improvements so that the organization can qualify as an ISO 9000 supplier (or other selected standard).

Finally, the team needs to put in place quality audits. The responsibility must be assigned to someone. The timing of the audits should also be specified to ensure that these are completed within the project timeframes.

As stated above, generally engineering will ensure that definition, design and development are structured to produce the best possible results.

This page intentionally left blank

Was this article helpful?

0 0

Post a comment