Basic
Development and Decision Processes:
Technical and Economic Analyses
Michael
Tekletsion Berhan
African Technology Forum
Copyright
2000
Published
on-line at:
www.africantechnologyforum.org
Development
and Decision Methods
for Products,
Processes,
and Services
· "No Input, No Feedback" Problems
· Internal and External Causes and Effects of Problems
Historically, many business and government entities - in all parts of the world, from the largest organization to the small entrepreneur - have approached the creation of new products and systems, even public services, without properly assessing their applicability. While invention, creativity, and good intentions are all great characteristics for an individual, business, or organization, they are not sufficient by themselves. In order to maximize the likelihood that the effort being put forth is a fruitful one, the entity investing the energy and resources must start with the target user... the customer or the public. Preferably both
As is known throughout the world, during the 1980s North American and Western European companies came to the realization that many of their efforts and investments were not reaping the rewards they were intended to. Beyond short-term financial ups and downs found in any marketplace, they realized that they were lagging behind their Japanese counterparts in satisfying their customers' needs. Many producers were seeing their competitors' products swiftly taking over their markets - and by large, decisive leads. Among other problems, there were three major errors that these organizations did not realize they were committing. The first of these was that they were not truly researching the end customers' needs properly and translating those needs into production actions and requirements. The second was that they were not including all the members and workers who were expected to deliver the goods or services, thereby not knowing if it was even possible to successfully deliver as organized. The third error was that these organizations were not looking ahead to the possible internal and external causes and effects of their deliverables' problems. They would proceed to put their product or service out, and only then inspecting it, looking at how it was received, and seeing what could go wrong
Let us discuss these three errors, study how to prevent them, and how to deliver the best products, processes, and services possible.
"No Input, No Feedback" Problems
Sometimes called "Eureka" design, the first major error in some ways predicts, and worsens, the other two. "Eureka! We've come up with the perfect answer for you - all by ourselves!" Once promised, the customer and the public expect to see the stated solution put into place, started up, and work. And, within the bounds of reasonableness and circumstances, they have the right to expect it to work correctly, continuously, and efficiently. They do not, and should not, expect to be subjected to excuses that failure occurred because of this-and-that. The party who promised the solution was paid to fulfill this need, not to leave the need unmet
While rational thought dictates that no one single entity has all the answers and that no one inventor or planner has the ultimate design, human nature sometimes lets us forget this truth. One person or one company or one organization can look at a given challenge or problem and, even after great thought, be mistaken in proclaiming the answer found before even asking the affected parties for their input. An answer is not truly found until the problem is solved in the eyes of the affected. It must not be shoved down their throats. The problem itself cannot be understood without the input and personal definition of the affected - the end user or the public at large.
Going beyond simple customer and public surveys, organizations must take the fundamental needs and wants of the people they are trying to serve and listen to them in those people's own terms. This unfiltered input is the most important resource any organization can tap, because it defines what functions they must truly serve and how their output will be judged. A dairy factory manager doesn't directly care if his or her factory's milk is processed with X or Y device. He or she cares, and will be judged by, whether or not their goods are safe and drinkable, produced on time, and reasonably priced. If your company promises to deliver X or Y device, and for whatever reason, that perfectly functional device ruins the overall deliverable of a properly processed, fresh, cost effective bottle of milk, market forces and the furious dairy manager will show you and your company's reputation to the door. Nobody will remember the fact that your wonderful machine did the particular task you yourself thought it should have. This example holds true for software, machinery, financial investments, medical care, and any other deliverable good or service. Satisfy the customers' needs in the manner that they want, or face the harsh consequences.
Once the end user's needs are listened to and carefully recorded and studied in the user's own environment, then the entity or organization trying to deliver the solution must spend their own time figuring out the particulars of their solution. These customers have better things to do; they expect you to remedy their ailment the same way a doctor should. Make them feel better. Do not ask the patient for a prescription, and do not provide a medicine that, for whatever reason, cures the wrong ailment. In modern technology driven industries, for example, this is referred to as translating the "voice of the customer" to the "voice of the engineer". This way, the engineer may formulate the solution in the most appropriate way and deliver an optimum solution back to the end user in a fashion the end user can see the most benefit from.
The work and writings of W. Edward Deming, Stuart Pugh, Genichi Taguchi, Don Clausing, and others shows us that this is an extremely important step, one that sets the tone, values, and measurement criteria for all other steps of the development process. Methods to transform the customer or end user input to internal detailed criteria and metrics are discussed further below. Called "decision matrices", they allow for review and selection of the most applicable of all available functions or designs in a cohesive, straightforward, and benchmarkable fashion.
Time waits for no woman, man, business, or agency. User input left to a single point or span in time is a remarkably static thing, usually taken from a small statistical sampling of the affected parties. The risk of focusing on simple static targets is that goods and services are used over a long time, by a large cross section of individuals and groups, in various dynamic settings and situations. Things change. Needs change. Resources can get scarcer for both the customer and the developer. During the development of a good or service, the organization must pay as close attention to the end user's situation as possible. Constant feedback is a must. Following the medical analogy, the patient can take a turn for the worse, or develop a second ailment that renders the cure for the first ailment useless or even dangerous.
It must be noted that North American and Western European nations and companies were not the only ones to fall prey to these problems in development. As technically proficient as their analysts, planners, engineers, and scientists could be, the Eastern block nations often suffered under very faulty systems and technologies. Unsustainable efforts were often used to continue the life of a given machine or plant that simply was faced with tasks harsher than it could handle, or environments that changed faster than it could react, or worse... needs that were misdiagnosed during the development stage. These nearly totally centrally planned economies were even more susceptible to injury from single source developments. There was no fully open marketplace to prove out most ideas, systems, and technologies in a survival-of-the-fittest fashion. This was not just a detriment to the item in question... it was supposed to be just a tool. It was, and remains, a serious detriment to the public or to the entities it was meant to serve and whose costly resources it spent.
This error is one that can suffocate and kill even the healthiest development or project in an instant. It is an internal example of "Eureka" design. When a particular function or design or structure is chosen to fill a need, it can sound like the greatest thing ever. That is, until it is put into place and it seems that the left hand did not know what the right hand was doing.
Where industrial businesses and organizations tend to see this problem occur is between their development, manufacturing, and/or financial operations. Often, a solution to a technical problem, say for instance a revision to a telecommunication network or the introduction of a new machine design, is hampered by the words "we can't do that". This can be for very good reasons, as often the well-meaning people who develop a new idea on paper are not the ones who then have to put it together or the ones who have to find the money for it. The developer thinks hard, comes up with a solution based on their own experience, and "throws it over the wall" to their implementation staff and laborers. The input of those who have to do the implementing, and who know the operating environment first hand, is often left out of the development stage of a project.
The solution is to include workers and representatives from the entire planning and implementation cycle of the project from the very first day. The dairy factory manager from the above example shows why this is crucial. Imagine the manufacturer of device X, say a bottle cap washing machine, did not know that the next step immediately after the caps are washed was a quick fill and closure machine, which takes the clean cap and twists it down on the top of the filled milk bottle. If historically the as-washed caps reached the closure machine at 75 degrees centigrade with the metal cap fitting the threads snugly, what could happen if the caps reached the closure machine at 120 deg. C? The maker of the device X cap washer might have thought, "Well, 120 deg. C will perfectly sterilize the caps even if the washing solution failed. I will give this customer this extra benefit!" This would be great, but what if, at 120 deg., the cap hadn't cooled and contracted enough to give a sung fit on the bottle's threaded top? Imagine if such a hot process made the stamped metal cap buckle? The improperly seated and sealed bottle cap could pass this stage unnoticed down the line, even reaching the packing and shipping stage. Now, what is expected to be a fresh bottle of milk reaches the customer sour from the lack of sealing.
The inclusion of the persons responsible for the fill and closure machine could have easily prevented this situation from occurring. Even asking for the input of the workers who maintain the machines could have raised this issue beforehand. No project can ever prevent all possible problems from arising, of course. However, the cost to get as much related input as possible from the inception of a development can usually prevent the vast majority of much more costly "real world" operating problems from arising. Losing the customer sales and respect due to improperly sealed milk bottles, and having to track down the problem from the field back through shipping all the way to the beginning of the bottling line, means huge revenue losses and a great outlay of labor and detective work. Early focus on concurrently developing a product, process, or service with all related personnel is an "ounce of prevention". Too often, even a "pound of cure" cannot save what might already be a mortally wounded product or service. Taking an idea that is developed by only part of the overall organization and "throwing it over the wall" to the next people in the process leads to great problems, both internally and out in the public marketplace.
Internal and External Causes and Effects of Problems
The third major error is the failure to forecast for, and protect against, all reasonably possible internal and external causes of problems for the product, process, or service to be delivered. Preventing these causes, and their subsequent effects, can help a good project be seen as a great one over time. Such preventative measures can help make projects and their deliverables highly "bulletproof" against false starts, cost overruns, and failure after deployment.
Returning to the example of the "device X" bottle cap washing machine and the exit temperature of the caps, what could go wrong with such a process? Envision a dairy factory environment in a developing country - or any country for that matter. The washing machine is connected to a water and steam supply, an electrical supply, and manual or computerized controls. It is stationed midway along the bottling line, amidst all the hustle and bustle and foot traffic found in many such busy factories. While such a machine should be at home in this environment, that does not automatically make it invulnerable to the risks and unintended problems the environment presents.
What if the temperature controller was susceptible to losing its setting? If it was designed to work between 75 and 120 deg. C, and not change unless manually reset, no variance might be expected. But what if the controller was prone to malfunction whenever the ambient air became too humid, and Device X Washer Manufacturing Ltd. didn't know this before they sold and installed the washer in the dairy factory? What everyone thinks are stamped metal caps being properly washed and passed along at 75 deg. C could now be 115-120 deg. C and buckled just enough to not seal yet escape undetected. What if the washing racks were designed to properly seat caps that were no bigger than exactly 2.5 cm in diameter and 0.75 cm deep, and the caps as stamped measured 2.4 +/- 0.1 cm in diameter yet varied from 0.65 to 0.85 cm in depth? Functionally, they might very well screw on and seal the bottles, but their improper seating in the washers could cause them to not be washed correctly, risking contamination of the milk. These would present what can be classified as "internal" causes of problems for the bottling process.
What happens if problems with the washing process arise from something that is not a direct function of the washer? The temperature controller might be accepting its inputs perfectly and setting the temperature right at the intended level, but what about unintended inputs? Imagine a temperature controller that takes its manual inputs via a "+" and a "-" set of buttons on a keyboard. In a busy factory, many people might walk by and rest a hand or a tool on the keyboard. With many other tasks in mind, they might do this without even thinking twice about the repercussions. If the "+" button is then accidentally depressed for 20 seconds, and if the controller reads every half-second as a one degree increase command, an initial temperature setting of 75 deg. C is changed to 115 deg. C. The resultant effect is an output of caps exactly at 115 deg., which the controller faithfully drove the washer temperature to in this case. This leads to the same lightly buckled caps we earlier feared. This situation can be considered an "external" cause of unsealed milk bottles, and another source of problems for the manufacturing process.
Of course, the terms "internal" and "external" are just nuances to an angry customer who wants to know who caused their milk to spoil way before it should have. Just as the end customer should not be forced to determine who exactly is responsible for the spoilt milk, the factory manager should not be faced with machinery susceptible to such problems. Device X Washer Manufacturing should have designed the controller keyboard to only accept intended temperature setting inputs. The two buttons in question ideally should have been covered with spring loaded flip covers, a single locked cover, or required a separately entered combination code before the setting could be changed. If those options were too costly, even simpler measures would be an improvement compared to allowing faulty inputs. If the keyboard had short brackets surrounding the four sides of each button so that only a direct push could result in an input being registered, this "external" cause would be unlikely to happen.
These concerns are just as present in services as they are with products and processes. The service in question could be related to a product or process. Customers expect many products, properly designed and processed of course, delivered to them as part of the entire service. These could be computers, spare parts for factory machines, vaccines, or even the milk from our example above. Avoiding customer disappointments and their subsequent effect of lost sales requires that preventative measures be applied to shipping and delivery services, for example, just as they are applied to factory lines. The service could be totally self-contained, like accountancy or legal services, and still be vulnerable to internal and external problems. Something as simple as client financial files generated on British A4 paper not properly fitting into an accountant's binders designed for US 8 1/2" x 11" sheets could cause damage to the file and loss of information. To the accounting firm, that would be an internal cause of a problem; to the client, an external cause. The subsequent effect of that once seemingly small problem could be a failed tax audit when bits of important financial data show up torn off of the sheets after the binders have been in transit to the authorities. No matter how accurate the bookkeepers might be, if such a failure did occur the client could still be furious, and rightly so. A business is there to ensure a proper outcome to their clients; there should be no unexpected failures.
Preventing the internal and external causes and effects of problems from occurring is not always simple, and in the real world nothing is absolutely bullet proof or invincible. The methods, however, to develop and implement the most technologically and economically solid deliverables possible for any given project are neither costly nor difficult. This is where the tools of Quality Function Deployment come into play, to prevent the three major classes of errors discussed above.
Quality Function Deployment, often called Total Quality Development or one of dozens of other synonymous names, is the overall methodology of taking the customers' or end users' needs in their terms, looking carefully at the overall environment any given solution might be used in, translating those needs into specific functions and tasks, and delivering well thought-out, forward-looking solutions to the intended recipients. In the preface to his book, Total Quality Development: A Step-by-Step Guide to World-Class Concurrent Engineering, Don Clausing states:
"Quality is achieved by systematic deployment of the voice of the customer throughout the organization and by the application of quality engineering to provide products that remain very close to ideal performance."
Clearly, this philosophy is not limited only to the delivery of great engineering products. Banks, government agencies, transportation fleets, power stations - any of these can be best developed using a systematic methodology which always focuses on every organ and every component working together to deliver the ideal and most robust good or service.
Total Quality Development methodologies are used in highly competitive modern companies to do everything from designing computer chips and aircraft systems, to developing software, to building delivery networks, to choosing financial investment opportunities. An overall review of QFD/TQD methodologies is beyond the scope of this article. It would be like a discussion of the scientific method... whole volumes can and are written about it. What can be discussed are a few major points of QFD/TQD. (It should be noted that while QFD/TQD sounds like Total Quality Management and the two practices are somewhat similar, they are not the same thing. The former guides product, process, and service development through to deployment. The latter guides process and service deployment and on-going management. QFD/TQD should be used to develop and handoff to TQM the thing to be managed.)
The first step is to thoroughly investigate the problem at hand. That, of course, sounds like what any logical person or group would do. The key is to investigate the issue in the location and environment where it occurs. For example, a mining company knows that it wants to mine a particular ore in a particular location, but how to set up the production facility and what particular production processes and equipment to use is not readily apparent. While a typical mining company of the past might have sent a surveyor, a geologist, and the manager of operations to look at the site, an even smarter company would also send a labor representative, a processing engineer, a company accountant, and the head of their present transportation department or contractor, at a minimum. This team would not only examine the site, they would examine and compare similar sites and operations already in existence. They would examine the environment the prospective site is in. What are the local conditions? Is the local power grid sufficient for indirect needs? Is the local drinking water supply far away enough from the proposed site to avoid a health risk to the public? Does this particular site look like it would require budgeting for highly unusual costs to start a mining operation here? It cannot be stressed enough that as many questions and potential risks to the success of the project as possible should be thought over at this stage by a wide range of the organization.
The next step is to truly capture all the desired requirements of the project in general, laymen's terms. The assembled development team should ask the board and major investors of the mining company, "What are the range of things you want this project to deliver, in your own words? What function should it provide?" The answers given might not always be what are expected. "A healthy, sustainable profit" of course means that the mining operation must generate more income than the sum of its costs. It could also mean that "sustainability" is very desirable, such that minimizing machinery costs to keep the initial investment amounts down and initial profits up is not what is needed. The investors, who neither need to know or care about how much could be saved from an individual building's construction on site, might be more interested in having a long-term stream of steady income. They may want to add to and cushion the ups and downs of their other, already volatile, investments. While coming up with a solution that only costs three million pounds sterling instead of ten million might sound like a great solution to some, if that is not the focus of the investor, the deliverers of that particular idea might have completely failed, however noble their intentions. Again, customers, investors, and the public will not judge you on your terms. You will be judged on their terms, in their minds, in their environments.
After capturing the requirements in their terms, the next step is the challenge of translating the customer's stated needs into particular functions that the organization and the project should deliver. "Sustainable" to an investor could very well be interpreted by the experienced manager of operations to mean a scalable production scheme. If the demand for the ore goes up, the production rates should be able to be swiftly increased to meet that need. If the electric power rates go up, in order to sustain production while not incurring a large cost hit, the machinery might need to be adjusted to work in a more energy efficient manner. Maybe these and other needs require that production flexibility is the major function the actual operating system development must provide. If the law requires that no waterways be polluted by any mining operations, it is up to the company to translate that to prevent such risk from occurring in various ways. Airborne pollution control must be a function provided, since particulates can settle in rivers, wells, and even find their way into ground water. Does the law in question explicitly mandate the control of airborne particles? No. Is this function implicitly required? Clearly, it is. As tools, the performance matrices discussed below can help in this translation from the stated desires of the intended customer to the more specific criteria the development team will use.
Once the overall functional requirements are translated, different proposed solutions for this stage of development must be thought out. This is the concept generation stage of Quality Function Deployment. Guarding against the "Eureka! We've found it!" phenomena discussed earlier, the development team must spend time looking at all possible ways to meet their challenge. The team must internally propose various operating schemes. "Variable speed processing lines" says the processing engineer. "Leased machines, to use only as needed" says the accountant. "Two eight-hour shifts five days a week, with the ability to switch to one ten hour shift six days a week when overall demand lessens" says the labor representative. Until all possibilities are exhausted, the team cannot truly know what solution, or range of solutions, will best provide all of the functions in the customers' and investors' eyes. Although human nature often makes us say "That proposal is simply wrong!" to someone else's idea immediately, no proof can be offered until the idea is fully heard and judged by the functional criteria translated from the customer.
The simple yet deceptively important reason why the concept selection stage, and the steps before it, is so crucial is that development projects of any kind are extremely difficult to change once they are set in motion. If the layout, machinery, and financing for the mining operation are set to return a terrific profit under today's economic conditions, yet six months from now the operation is bleeding great losses because it simply cannot be altered that easily, its overall concept was wrong. It was not "sustainable", and the investors, the board, and those customers who are awaiting shipments that are sitting parked because the truckers' fees could not be paid, are going to all be upset.
Updates to this guide will
continue to be posted to this site...
so please keep your eyes and web browser bookmarks focused here!
Michael
Tekletsion Berhan
African Technology Forum
Copyright
2000
Please note that African Technology Forum Consulting may be contacted to provide detailed examples of how to apply these tools to a particular situation. Visit www.africantechnologyforum.org, or write to us at africantech@att.net, mtberhan@alum.mit.edu, or mtberhan@att.net for any such assistance.
References
Clausing, Don P., Total Quality Development: A Step-by-Step Guide to World-Class Concurrent Engineering, American Society of Mechanical Engineers (ASME) Press, New York, 1994
Deming, W. Edward, Out of the Crisis, MIT Press, Cambridge, MA, 1986
De Neufville, Richard, Applied System Analysis: Engineering Planning and Technology Management, McGraw-Hill, New York, 1990
Merino, Donald N., and Lang, Hans J., The Selection Process for Capital Projects, John Wiley & Sons, New York, 1993
Samuelson, Paul A., and Nordhaus, William D., Economics, McGraw-Hill, New York, 1992
Slocum, Alexander H., Precision Machine Design, Prentice Hall, Englewood Cliffs, New Jersey, 1992