put in place a series of tests to validate that the designed (and built) product will meet all stated requirements and specifications. In most cases, the tests of hardware will test to limits beyond the specifications to allow for part/product variability during the manufacturing process. The Test Plan may also specify that usability or field testing be conducted as lab testing cannot verify all aspects of the product anticipated use. This type of detailed testing is in addition to all the testing that will be done by the Development group during the development process.
A company’s marketing staff find a product need and convey this to the company’s development branch for consideration. If a trial is deemed reasonable, the proposed product is designed, reviewed and, if approved, a model is then developed and sent to the company’s testing organization. They in turn develop a test plan, which is reviewed with the developers, followed by a series of appropriate tests. Such tests may involve controlled environmental trials, noise levels, vibration, etc., conducted within lab facilities, or they may be conducted at field locations, especially where usability questions must be addressed.
Problems get corrected and testing is repeated. If the testing is successful, the product is released to manufacturing and initial production units, typically three to ensure for parts variability, are again subjected to planned testing. Once again, testing may include field testing in selected business environments. When the product successfully passes through the testing, it is released to full production and shipment to customers. Throughout this testing process, the product market is continually reviewed against Market Requirements and System Specifications in order to ensure the product is going to achieve its expected market, both in costs and revenue. This is a very brief description of the development, testing, and manufacturing cycle employed by many successful industries.
The market has many examples of successful companies, companies that exhibit fiscal responsibility, controlled product development and release, and quality control of the product release. If examined closely, it will be found that their good practices help them remain competitive and successful in the market today.
Industry is not above suffering from the lack of, or poor definition of, Market Requirements. Three famous failures come from the automotive world with the Ford Edsel, the DeLorean, and the Tucker. In the cases of the Edsel and the Tucker, the cars were of a futuristic design, and simply not accepted by the buyers. Ford Motor Company spent over $250 million for the Edsel, but in the end the car line was dropped due to the lack of buyer acceptance. The Tucker suffered from problems of too many user options, and failed after only 51 cars were built. In the case of the DeLorean, the cost of the automobile was far beyond any other at the time and thus suffered poor sales. The DeLorean may be best remembered as the automobile used in the movies Back to the Future.
The authors had the experience of being involved in a new process control computer system that had all appearances of being a unit with a wide open application base. Although the unit had good Market Requirements and a Product Specification that had gone through the normal rigorous process, somewhere something got lost. When the new product reached Product Test and entered usability testing one major flaw was found: the unit only had paper tape as an input/output device! There was no way to write, compile, or execute programs on the unit without using some other system to prepare the program tapes for loading. Totally unacceptable for the most simple applications, the problem had to be fixed before the system entered the market. The problem was corrected, and the product went on to be one of the industry’s most widely accepted process control systems.
In each of the situations described, the lack of good Market Requirements and Product Specifications could be seen as the primary reasons for the failure or poor results for the particular project.
The authors had the experience of what could be called “Ugly” projects. In the first case, the project was a new process control system which included, as an option, an arithmetic unit that included binary-coded-decimal (BCD) arithmetic and conversion hardware. As Marketing believed that some users would not want to include the cost of the arithmetic unit, a software emulator would be required to support BCD arithmetic applications. The emulator project was funded and development completed. When the system entered Product Test, the project failed miserably. Whereas most BCD operations performed in the hardware were measured in micro-seconds to complete the desired operation, the emulator took an extremely long time. In some instances, rather than MIPS, the unit was said to perform in furlongs per fortnight. Needless to say, the emulator was never released and the hardware unit became the standard system.
In the second case, the project was a shipboard guidance and collision avoidance control system. The proposed system had international impact, and was viewed as being a great prospective revenue producer for the corporation. The product went through the normal testing process, including extensive sea trials and appeared to be an unqualified success. Unfortunately, when the Market Requirements and Product Specification were written, the Service aspect of such international travel was not taken into account. As a result, when a problem did occur, the service engineer might have to be flown from one country (where the service center was located) to another where the ship was docked. In some cases, the service engineer would have to be transported to the ship at sea via a helicopter. To further complicate the servicing aspects of the product, in some cases when the ship docked at a new location, the service engineer could not leave the ship, as his or her passport was not acceptable to that country and the engineer would have to remain on-board waiting for the next port of call. The product was not as successful as had been hoped.
Project successes can be measured by cost, time, and revenue as constituent parts. In most projects, the better the Market Requirements and Product Specification, the higher the probability that the project will be a success. This doesn’t mean a lengthy tome, but a set of documents that fully explore the anticipated market and user. Add to that the rigorous review and test processes needed, and, for each level of control, the higher the probability of success. Understand the process, work the process, and ensure your projects stay in the good regime.
A product’s success, or failure, may often depend on how well the product was defined before it was developed. Some products based on a developer’s concepts may become popular and in demand, but in most cases, because of the narrow perspective of a developer’s specific application, such products rarely hit the high revenue mark. To raise the probability of success for a newly announced product or product enhancement, both the marketing and development communities must have a road map of the direction they wish to take. These road maps are referred to as Market Requirements and Product (or Technical) Specifications, both of which are required for the Testing organization to develop a comprehensive Test Plan. The more complete and detailed these two documents are, the greater the probability that the product will succeed in the market place.
These two documents are not developed in a vacuum by each group, with Marketing (which often includes the Sales Department, which is responsible for the day-to-day-in-the-face exposure to the customer) writing the Market Requirements and Development the Product Specifications. Marketing may ask for new, not yet invented, technology, and Development too often then provides a timetable that is too long and too expensive. Such differences must be negotiated and resolved. Special features may require new algorithms, or other development work that will not meet Marketing’s expectations — and the features may be so narrow in scope that their absence will not affect the overall acceptance of the product by the user community.
In many cases, the Marketing and Development groups will modify and discuss both documents until a consensus can be arrived at in order to meet the market needs, in a reasonable time, at a reasonable cost, with the most highly desired features present. In addition to Marketing and Development, three other organizations are called upon to help ensure the product requested and the product delivered are the same.
