Basic Development and Decision Processes

Now we will discuss specific tools that help guide individuals and teams development and decision processes. They can be grouped into two areas, performance matrices and decision matrices. Just as the performance matrices discussed below can help translate the intended recipient's needs into functional requirements, decision matrices can greatly facilitate the selection of the most appropriate solution from a set of concepts and proposals. They are very helpful when used even by themselves. They are even more useful when used within a comprehensive application of Quality Function Deployment/Total Quality Development.

Please note that the term matrix is used loosely in this work; not necessarily in the purely mathematical sense. They can be simple text lists or detailed schematics. While many find graphical matrices particularly useful, any list or ordered diagram or numeric structure can be considered a matrix in this sense. Likewise, any matrix can be presented as a list. As with all tools, let form follow function. Choose what works best overall for you in a given situation.

A Cause and Effect diagram is a graphic listing of what can occur in a given process, good, or service, and what causes, or goes into, that occurrence. It can look like a tree, with the tree top being the desired effect or function and the roots or branches stretching out to enumerate all the required sub-functions and developed criteria. Below is a highly, highly simplified function tree covering fiscal, physical, and intangible criteria.

Particularly in the development of physical products and processes, function trees can be used to enumerate all of the necessary and sufficient parameters. The required values or ranges of these variables become the ends of the branches as seen in this example.

The converse of a function tree is a fault tree. Simply put, instead of showing what is needed to deliver the function in question, a fault tree shows what can go wrong and how. Product, process, or service variables that are outside of their required ranges can cascade all the way throughout the system and destroy its ability to deliver the desired functionality. Because of this, there are infinitely more ways for a system to go wrong than for it to go right. Fault trees are often drawn bigger and more intricate than their corresponding function trees need be.

Fault trees are more commonly called cause and effect diagrams, and unfortunately are often only utilized during failure analyses... after the fact. They are very powerful tools for forensic-style detective work. The help to perform autopsies on failed systems and components. Where did we fail the customer? What particular failure modes were in effect? What were the causes? Breaking down the function to all of its possible parameters that may have gone wrong, along with all possible unexpected external inputs can find and help fix the problem.

A histogram is a bar chart that counts the total number of items or frequency of events that fall into different categories or ranges within one general system or scheme. A Pareto chart is simply a histogram where the categories are sorted from highest to lowest percentage of some sum total. It is very useful when trying to determine which criteria are most important, or what are the largest challenges. In this example, it is seen that sealing is the largest cause of milk spoilage. A simple tool, but it helps focus attention on the main issues one must deal with.

Often decisions are made based on only one general criterion: how great an idea sounds, or how much better or worse it is than some set of alternatives. While sometimes decisions must be made in a very short time, it is a great risk to make any important decisions based only on what is essentially one side of a coin. Spending the time to review and document both the positive and negative aspects of any concept or set of possible actions can make all the difference to a project's success.

A simple yet well thought out "pros" vs. "cons" list, enumerating the positive and negative aspects of each available option, can provide huge benefits to every stage of a project. Of course, this might sound overly simple. However, anyone who has worked on complex projects has sooner or later seen stages where unexpected problems arose from decisions that were only based on the positive benefits that a particular option promised. The negative aspects were not properly assessed, and the problems that arose were compounded by the fact that no one was ready for them. Resources already budgeted for other purposes, if they even exist, are re-routed in order to correct these problems, thereby only cascading the problem's effects.

Nothing can eliminate all costs, tradeoffs, and problems from all project development options. What is crucial is evaluating each option or concept for all of the positive and negative aspects that the involved team and the customers and end users might face. These positive and negative aspects can be grouped to help analyze the options further. For instance the "pros" vs. "cons" for a machinery purchase could be listed as follows:

Machine A	Positives, or "pros"	Negatives, or "cons"
Cost
Purchase cost	Low financing charges and flexible credit	Moderately high purchase price
Operating cost	Low power consumption	Highly skilled operators required

Speed & time
Cycle time	Fast and consistent
Start-up time		Slow start-up time due to low power rating
Mean time between failure	Very durable, high reported time between failures
Mean time to repair	Authorized personnel can repair quickly	Manufacturer certified technicians required by warranty contract

Even taking an example where only one option has been raised, listing the positives and negatives of that option can help improve it or guide the development of other options. What changes or totally new concept could retain or improve the positives aspects of the first option while reducing or eliminating its negative aspects? Even if no changes are found to be feasible, and the original option must be implemented, at least there should be no major surprises and the interested parties will be prepared for the tradeoffs.

A "pros" vs. "cons" list is the most basic of decision matrices an individual or team can utilize. The other decision matrices listed below, however, share its guiding premise of thoughtfully laying out as many aspects of a decision's options as feasible. In fact, the closely related Cause and Effect, or Function Tree performance matrices discussed above can be utilized to do much of the same, but are often used to focus on the tangible functions and characteristics of particular options. Decision matrices are helpful in including the "intangibles" that surround any set of options, such as cost, timing, and impact on other stages of a given project, and determining which option best suits the role.

Pugh charts take their name from Dr. Stuart Pugh, a professor from the University of Strathclyde in Glasgow, Scotland, who studied the way product and process development projects were performed. Pugh charts are decision matrices somewhat similar to the afore-mentioned "pros" vs. "cons" lists. They are, however, used for evaluating multiple options against each other, often in relation to a baseline option. Rather than just listing the positive and negative aspects of one option, general criterion by general criterion, a table is made which lists all of the project requirements at a given level of detail in one column. These criteria can either be weighted by importance and subsequently ranked, or arbitrarily laid out in whatever particular order suits those making the evaluations.

The following example shows three options for the previous machinery purchase. It compares the three options using an unranked Pugh chart to a machine that has already been investigated. In much of the literature, such a baseline comparison target is called the datum. It serves as the control, to help remove the subjectivity that comparing selection options against one another can sometimes involve. Each option is rated against the datum, since the datum represents the present situation the decision makers face. The winner of the analysis is the option that ranks as the highest improvement from the present situation when judged by the given criteria. For each criterion, each option is judged by the team's vote as to if it fulfills that particular requirement either better than, worse than, or the same as, the datum. Better than is denoted as a "plus", worse than by a "minus", and a "same as" result is noted as such. If the development team wants to then compare the options to each other directly to make sure they chose wisely, the analysis can be performed a second time with the winning option as the datum. The objectivity of the first decision is typically shown by the remaining options still coming out with less "pluses" and/or more "minuses" than the new datum.

If no single option sticks out as a clear winner, redesigning some of the options might create new and better concepts. Taking the best characteristics shown per criterion, per option, hybridized options can be developed where feasible. They may then be analyzed in comparison to the datum. If in the above analysis, for example, machine B's cycle time was actually much, much longer than machines A's, the team could enquire if the electric motor found in machine A could be retrofitted to machine B. If feasible, this would allow for a new option - let's call it machine B-2. Machine B-2 could be analyzed by the same criteria, and could wind up the winner with just a slight increase in purchase cost.

The criteria used in the previous examples can be given importance weightings by the development team. If immediate budgetary constraints will force the up-front purchase cost of the selected machine to be the most important consideration, how does this criterion compare with the remaining factors? Process cycle time and its associated labor cost will always be a major component of any production budget. Maybe in this situation the team knows that start-up time plays a factor in productivity as well, but since the machine will be running nearly continuously throughout the day, it is only a relatively minor concern. Using an arbitrary scale of one-to-ten for the relative importance of each requirement to the overall goals of the project, the team could weight the factors as such:

Criteria	Importance Ranking
Cost
Purchase cost	10
Operating cost	5

Speed & time
Cycle time	7
Start-up time	1
Mean time between failure	7
Mean time to repair	2

The criteria can then be rank ordered to help visualize what requirements are most important to the task at hand, and which ones are not as vital. The various options are then judged by the team as to how they meet the requirements. Under the ranking method the options can be numerically compared to the datum, again using an arbitrary scoring scale such as negative ten-to-ten. Instead of "plus", "minus", and "same", a quantitative value or score is picked. It should enumerate how much better or worse each option fulfills the requirements better than the datum.

If the team feels that the qualitative scores for each option were independent and objective enough, then they can feel confident that the analysis need not be performed a second time with the winning option as the datum.

Many authorities on this method, including Dr. Pugh and Dr. Clausing, have urged some caution when using importance weightings and rankings. The argument is as follows. While development teams weight different criteria in order to get the most objective rankings and overall decision effort possible, precise weighting factors can be hard to develop and get a team to agree upon. Also, both the relative importance rankings of one criterion to another, and the scores determined for each option per criterion could themselves be subjective to some degree. Thus, the added time it can take for a team to develop and agree on particular scores and importance weighting factors might sometimes be greater than the added precision this method produces. As a QFD/TQD tool, however, ranked Pugh analyses can usually help to deliver the option that best fulfills the customer and end-user's requirements. The team will also gain greater internal understanding of all the impacts of each option.

One fact is extremely crucial to keep in mind. The added time it takes a development team to analyze the scores and weighting factors is usually much shorter and nowhere near as costly as deploying the wrong solution to a project. Ranked Pugh analyses help to ensure to all interested parties that the available options were judged with as much objectivity as possible, and that the most important criteria were the predominant factors in the decision. Of course, if a balance of objectivity, precision, and time needs to be struck, lower weight criteria can be removed from the chart. This way, the team can make the decision based on only the most important requirements, the "heavy hitters". Even the importance weights themselves can be thrifted for time. For instance, instead of a scale of all the numbers from one to ten, a "high" weighting could default to ten, "medium" weightings could be represented by five, and relatively "low" importance ratings could be represented by two or one.

The Analytical Hierarchy Process (AHP) is a decision matrix methodology that relies very heavily on quantitative scoring to select options that best fulfill the criteria at hand. In this sense, it is similar to a ranked and weighted Pugh chart. An AHP matrix, however, should most often be used with highly quantitative values for each option's score per criterion. This further reduces the subjectivity of the qualitative scores often used in a Pugh chart. The Analytical Hierarchy Process, as one can infer from is name, is most appropriate for purely analytical and complex decision making, where multiple variables come into play in diverse fashions.

Just as in the weighted Pugh analysis, the general, or higher level, criteria driving the decision at hand are given importance ratings. The sub-criteria that make up the detailed requirements at the next level of importance to the project are then listed and given their own weightings. This is essentially functional decomposition, whereby criteria at each level are broken down into their components. This allows for the final decision amongst several options to be made by considering their overall values derived from their various detailed characteristics. The use of the Analytical Hierarchy Process can be coupled well with function trees for the decomposition analyses.

An AHP matrix is constructed as follows. The individual or team who will be making the evaluation takes the highest level criteria and must determine what they find to be the relative weightings of each parameter. A diagonal matrix is laid out, with the parameters set as both the column and row headings, and the diagonal of the matrix populated with ones. Going horizontally across the first row, the relative weight of each parameter with respect to the first parameter is determined and entered. An inverse value is used when going horizontally, so in the example shown below, the impact of one unit of cost is considered three times as important as one unit of speed, and twice as important as one unit of durability. These values are entered in the spreadsheet in the cells shown in bold. Each row is then divided, or normalized, by its matching parameter. Thus, in this example, the second row, which represents values relative to speed, has the values from the first row divided by three, the value of speed in the first row. The same operations are performed for the third row, normalizing by durability's value of two.

Performing these steps across the matrix horizontally is arbitrary, since the same can be done by performing this operation vertically, column by column. In fact, inverse weightings don't have to be used in that case. Direct ratings can be used in the first column with the same end result, since the diagonal properties of the matrix can be seen as below. It can, however, be easier to see and read the following steps on a spreadsheet when done horizontally.

The overall priorities of the criteria must then be calculated. A simple way to do this is to find the geometric mean of each row. The geometric mean of n variables is (X1*X2*... Xn) ^ (1/n). Here, taking the cube root of the first row's grand product, cost is seen to have a priority with respect to the overall scores of (1 * 3 * 2) ^ (1/3) = 1.817. Speed has a priority of (0.333 * 1 * 0.667) ^ (1/3) = 0.606, and durability has a priority of (0.5 * 1.5 * 1) ^ (1/3) = 0.909. The geometric mean of the sums of the individual weightings also works out to be the sum of the priorities, as (1.833 * 5.5 * 3.667) ^ (1/3) = 1.817 + 0.060 + 0.909 = 3.331. In order to use these highest level weightings as overall percentages when cascaded to lower level parameters, the priority values are normalized by dividing the column by the sum of the priorities, 3.331. Thus, for this decision process, 54.5% of the decision should be based on cost, 18.2% on speed, and 27.3% on durability.

The next level of the analysis must decompose the higher level parameters into their own components. The same weight determinations and mathematical operations are performed for the lower level parameters, and their own locally normalized priorities are calculated. The step that is added here is to multiply the locally normalized priority for each lower level parameter by the normalized priority calculated for their shared higher level parameter, creating individual weights for each lower level parameter. This operation can be seen in the last column of the following matrices.

Lower levels of normalized weights can be seen to add up to the total priority given in the next highest level of functional detail in the matrix. For example, the normalized weight for purchase cost was 0.182, and the normalized weight for operating cost was 0.364. This essentially means that 18.2% of the total value of the selection can be represented by purchase cost and 36.4% can be represented by operating cost. Note that the two weights together combine to equal 0.545, which was the total percentage of the selection governed by cost. These normalized weights can now be used in ranked Pugh analysis as importance weightings. The individual quantitative scores given per criteria for each available option can be multiplied by these AHP importance weightings to objectively select the best of all options.

Alexander Slocum's engineering text Precision Machine Design discusses the methodology a bit further and in a higher level of detail. The text shows a good example of AHP analysis for high-precision machinery bearing guide-way selections [pp. 24-27]. Dr. Slocum makes the good point that the AHP method is quite well suited for implementing via spreadsheet. In fact, due to the repetitive calculations used to keep the matrices diagonal, normalized, and fully multiplied, many people might want to only use AHP for multi-level decision projects if they have a computer spreadsheet ready. They might want to default to more simple weighted Pugh charts for hand calculations. (Pre-formatted Microsoft Excel AHP spreadsheets are available from African Technology Forum Consulting if the reader is interested in using them as templates. Write to us at mtberhan@alum.mit.edu for such a file or for assistance with this or any methodology shown herein.) Even if the AHP method is not used by the reader for their own work due to its complexity, AHP's use in development and decision projects warrants an explanation of its details. Don Merino and Hans Lang's text The Selection Process for Capital Projects also details the use of the AHP method, this time for multi-attribute investment analyses.

The House of Quality is more than just a decision matrix. The House of Quality (HOQ) method is a very comprehensive QFD/TQD methodology that utilizes Quality Function Deployment practices, function trees (or other performance matrices), and Pugh chart (or other detailed decision matrix) selections to arrive at the best outcome for a given development project. The multiple-level decision matrix used in this method ties together all these other tools. It takes its name from the fact that this matrix can be seen to resemble a house in some cases.

The HOQ matrix methodology uses as its inputs customer and end-user requirements. It converts these "voice of the customer" (VOC) inputs into more exacting, specific requirements as interpreted by the development team (often called "voice of the engineer" or VOE in the technical world). It then compares the VOC inputs and the specific requirements to characteristics of similar products, processes, or services if any are known and available for comparison. Measurable targets or performance "metrics" are developed to capture the specific requirements. The metrics generated are then used in a Pugh analysis to determine which of all available options will best satisfy the customers and end-users in their own minds. Once a general solution, such as a system-level governmental service structure is selected, and verified to meet the VOC inputs as originally stated, more detailed sub-system options can be analyzed and selected. The output of one level of HOQ analysis can become the input to the next, more detailed level, until the final items and components of the overall system are selected in as fine a detail as feasible.

As it is just as applicable for developing a service as it is for a physical system, let us examine how the HOQ methodology could be used to design a curriculum and teaching structure for a technical institute in a developing country. In this case, the service's customers and end-users are this particular nation's public in general, and the students in particular. Of course, there are many ways to structure any organization, but the object is to maximize the benefit to all concerned regardless of structural detail. Again, form should follow function.

The Ministry of Education is mandated by the Prime Minister and Parliament to do the following:

As often happens in many fields, the initial project requirements range from specific, as in the budget figures, to quite vague, as in delivering "the most relevant way for the nation to maximize its overall benefit". This is when the people involved in the development and selection of the proper solutions must use a thorough process to build up and convert these "voice of the customer" inputs into more exacting, specific requirements.

To address these wide-ranging requirements, the Ministry of Education decides to make the initial VOC inputs more substantial. It starts by following two parallel avenues. The Ministry sets up two teams to gather more insight into these five stated requirements. One team will poll a demographic cross section of the nation's high school students who express an interest in technology or business. It should ask them what they want to become, and what technical subjects, if any, do they already think they want to study. This team will then poll the nation's indigenous technical professionals, industrial business leaders, secondary school principals, and even some number of its émigrés who work abroad in technical fields. These people would be asked what types of curriculum courses, faculty, and administrative structures, in their opinion, best fulfill the first four mandates.

The second team will perform a benchmarking, or comparison, analysis. This will compare technical institutes, collegiate curricula, and technical professionals' educational backgrounds in other developing countries in the region, in extra-regional developing countries, and in fully developed industrial nations. This benchmarking analysis should examine how all the mandates, including the budgetary issues, are addressed in practice elsewhere. The analysis should also note any discrepancies or unaddressed challenges in the stated requirements when seen through the lens of these other environments. The two teams should remain in communication during their work, so that questions raised or surprises found by one will be taken into account by the other. This allows for more comprehensive information and better results overall. The decision to split up the feedback and benchmarking efforts is mostly for time saving and logistical purposes. Where feasible, in a HOQ analysis the same group of people should perform both the customer interviews and the benchmarking studies.

These review teams and their information give the project its very crucial first step. They provide detailed contextual information about the project and its deliverables. What particular real world measures would these mandates be judged by in the students' and the public's eyes? What socio-economic and possibly political environmental factors come into play that could help or hinder the institute and its mission? Are any of the first four mandates "wants" but not truly "needs" for the nation's public and students? The makeup of the teams is important. It is highly preferential to include people who will themselves make both the general and specific decisions for the structure and curricula. It is also best to include people on these teams who will actually deliver the service requested. A few people who are expected to be members of the teaching faculty should be on both of these teams if the logistics allows for it. All in all, as comprehensive a cross section of the development team and actual service providers as possible should be represented at this crucial stage of customer interaction.

After this interaction with the project's intended beneficiaries, the Ministry of Education gathers the information from the two teams and lays out what inputs they feel are relevant and what don't apply to the project. The two teams should now be combined into one and review all inputs and notable comments, so they all have a good feeling for what the various voices of these customers are saying. While reviewing the VOC inputs, the combined review team will most likely notice similarities between many of the responses, and will notice patterns and natural sub-groupings of the customer "wants" and "needs".

Many of the inputs will likely deal with cost. "Make the cost of attendance affordable." "Allow common people to be able to attend." "Don't make it so students will have to drop out for lack of money." "Most of the students will need to be working in a few years, don't have their studies drag out too long." Many of the inputs will concern applicability to the environment the students will face. "Give them degrees and experience they can use." "Let them study things they can work at in this country." "Give them exposure to the industrial community within our nation." "Will they be able to use information technology and other modern tools, or will they start their careers still behind their compatriots in developed countries?"

The review team should assemble these general requirements into as many separate and interdependent groupings as feasible. Utility to the students, cost, industrial benefits, estimated graduation rates, range of offerings, faculty experience, etc. can all have multiple ways to be measured and can obviously have many layers of sub-requirements. Seeing the groupings will help point out the nuances and interactions each area. It also lessens the chance of overlooking important requirements that may have only been raised by as little as one person. Common terms can be used within groupings to reword and clarify the inputs. It is highly likely in this case that the groupings will be aligned closely at a minimum with the five mandates given to the Ministry.

After grouping and clarifying the inputs, it is then time to characterize these needs before detailed project requirements are distilled. While not reflexively throwing out any area of customer input without at least minimal consideration, most projects have some range between possible feasibilities and clear non-feasibilities. The feedback might show that many of the secondary school principals surveyed want the institute's students to be required to serve as secondary school teachers as well. Wouldn't this help the nation "maximize its overall benefit?" While this might help ease a shortage of highly educated teachers, it is seen by nearly everyone on the review team and in the Ministry as a whole to be beyond the feasible scope and mandates of the project. The stated need is very important, but it will have to be solved by a different undertaking. It just is not applicable in this instance. Providing more secondary school teachers cannot be a "need" for this project to deliver even though it is clearly more than a luxury "want". Particularly in LDCs, such constraints can be frustrating to the customer and the development team alike. The focus, however, must remain on the most important deliverables within the mandates and allowable scope of the project.

A list of the requirements that were found to be relevant to the project and its mandates is made. Of all the customer inputs and requirements found to be relevant, the review team must determine what the relative importances of these requirements are. This step is identical to that seen in the Pugh selection process. The requirements can be listed by their common groupings, so as to help show the interrelationships inherent in any such undertaking. The list is presented to the same customers and end users who were polled. They are asked to individually rate how important they feel each requirement is. A one-to-ten or a high-medium-low scale could be used. Once all of the rated lists are returned, the review team averages the multiple ratings per requirement to generate a final score for each requirement at this stage. The requirements are then rank ordered by these final scores. The list might conceivably look something like this:

The list now makes up "Room One" of the House of Quality matrix. The next step is to translate these VOC requirements, which are still in laymen's terms, into the detailed requirements needed to proceed with developing an actual deliverable. As previously mentioned, in technical product and process development these translated detailed requirements are often called the "voice of the engineer (VOE)". This reflects that while the customers and end users know what they need and want, they know it in terms and mental images they are personally familiar with. It is up to the engineer to determine what specific, quantifiable details reflect those needs and wants. After all, they have to deliver the solution via certain steps, in a detailed, precise fashion. In non-technical or service development projects such as this one, we can replace the term "VOE requirements" with "specific requirements".

These specific requirements must accurately capture and define the VOC requirements. The specific requirements when listed out make up "Room Two" of the House of Quality matrix, as will be shown below. Room Two should look like a detailed version of Room One, at least to one level of functional detail. The Ministry of Education now takes members from the joined feedback and benchmarking review team and adds the remainder of those ministry personnel who will directly be responsible for creating the technical institute. This becomes the translation team who will develop the specific requirements list.

It should be noted that each particular VOC requirement could obviously translate into several of its own detailed requirements. (Again, one good tool to do this detailing and decomposition is the function tree described above.) This is perfectly natural, and it will be seen shortly that the same reduction that was undertaken with the VOC requirements to get a manageable Room One list can be undertaken with the specific requirements. The translation team, after analyzing the Room One list, studying their information on relevant institutes and other benchmarking data, and using a few performance matrices to analyze the desired functions, creates the following specific requirements list. The particular parameters and values that actually satisfy each specific requirement will be determined later. This list can be given an alphanumeric indexing to keep track of its contents.

Specific Requirements - Room Two
A	Offer mechanical, chemical, electrical, industrial, and civil/environ. engineering undergraduate degrees.
B	Offer geology and computer science undergraduate degrees.
C	Offer masters degrees in those departments with sizeable undergraduate enrollment, where budgetable.
D	Pursue dual-degree programs with other universities to offer masters' and doctoral programs where the budget does not allow for them in this school alone.
E	Establish an economics department that will also teach micro - and macroeconomics to other majors.
F	Offer e-mail addresses and at least text e-mail access to all students and faculty.
G	Establish Internet and basic website authoring labs on campus.
H	Offer an income tax break for the first five years that an employed graduate stays in the country.
I	Technical and economic faculty job candidates who have prior experience of two or more years in technical industrial companies will be given preference in hiring.
J	Mechanical, chemical, and electrical engineering undergraduate degrees will have design/analysis concentrations, and concentrations in processing/manufacturing.
K	Technical and industrial businesses and government departments will be selected as partners to offer internships to students in the relevant majors.
L	Product or process design theses will be required for graduation from engineering and comp. sci. majors.
M	Analysis theses will be required for graduation from geology and economics majors.
N	All course curricula shall utilize technical and financial classwork examples and case studies focusing on both national and foreign companies and organizations.
O	All students are required to work for the institute on campus at least five hours per week each semester that they are enrolled.

Now that the specific requirements list has been created, the House of Quality matrix is laid out. The VOC requirements are laid out as one axis, typically as a vertical column on the far left, and the specific requirements as the other axis, the horizontal row at the top of the matrix. The interlinked relationships between the two constitute the HOQ's "Room Three". Here, the translation team must now try to determine how closely each specific requirement defines the VOC requirements.

It is very rare that all of these relationships will be one-to-one, with each relationship tightly coupled. Ratings are used to determine the strength of each relationship. Again, a one-to-ten or a high-medium-low scale could be used. For this example, let us say that a numeric high-medium-low scale is used to help simplify the process. A 10 would be used to show a high level of correlation between a specific requirement and the VOC requirement it is attempting to define. A rating of 5 can be used to show a moderate relationship; one that is not as defining as the 10 would signify but where the specific requirement is still a significant factor of the VOC requirement. A rating of 1 can be used to show a small yet measurable relationship of the specific requirement to the VOC requirement. For the majority of the matrix, where there is no relation between a particular specific requirement and a specific VOC requirement, a blank or zero rating is left.

Just as there may be disagreement with the importances of various VOC requirements when they are being gathered and weighed for Room One, there can be disagreement among members of the translation team as to how closely certain specific requirements define their VOC requirements and what scores to give the relationships in Room Three. This can be dealt with in several ways, depending on the trade-off between the project's time and accuracy. If time is of the essence, then each member of the translation team gives an individual score for each relationship on the matrix, and the scores are then averaged. If accuracy and understanding the details and nuances of the project is still more important, then the team can vote on each relationship's score. Most relationship scores should be fairly unanimous, or without much variance, but some scores will be debated by different members. This is important, and should not be taken lightly.

Even when going for the most accurate results, the team should treat the matrix development with an eye on efficiency. It can take quite some time to go through all of the details, especially if there is debate on various requirement relationships. That being said, however, there is great value in having a large majority of the team agree on the details. Here, the team includes members of the Ministry of Education who will themselves be managing and delivering the particular services to the end users. It is generally much better to maximize clarification and certainty of purpose before a product, process, or service is deployed than to waste the opportunity to deliver a consistently high quality output. As with all other QFD methodologies, the idea behind a HOQ is to work smarter and more focused in the beginning and deliver something that is well thought out and stands the test of time in the end users' minds. Here, the Ministry of Education, who has to answer to the Prime Minister, Parliament, and the nation's citizens, as well as find a place to educate many of its own members' children, wants to ensure its output is robust and worth all the effort.

Now, regardless of the method used to determine the relationship strengths, the translation team finalizes the Room Three analysis. Going down the columns, the importance of each VOC requirement is multiplied by its relationship score relative to the specific requirement being looked at. Totaling these results in each column gives a fully weighted importance to each specific requirement. This way, the impact of specific requirements that help define more than one customer requirement can be properly accounted for. The specific requirements are then rank ordered by these fully weighted importances.

This output from Room Three allows for a detailed and focused Pugh analysis to be performed, using those specific requirements determined to have the most impact on the overall decision. As with Room One and the VOC requirement reductions, if the team feels that there are still too many specific requirements to make this Pugh analysis they can choose to remove those that fall under a certain weighting, say 60 in this case. Again, the team must decide the trade-off between time and the level of detail they can deliver. Since we have already shown how a Pugh selection process is performed, we will leave this House of Quality example at this point. The Ministry of Education now has a set of detailed criteria by which to develop and select between various options for their technical institute. The Ministry can select the best concept that fits within the budgetary constraints of the fifth mandate. They and the public they serve can know that whatever concept is chosen, it was developed and selected based on the guiding input of both the public and experts.

In this service example, the development of the project was handled by several teams throughout its various stages. This is often the case in large organizations, or organizations where the workload absolutely precludes having any one group focus on one project only. Of course, one development team can be successfully used throughout a project. This often occurs in product or process subsystem engineering, where the depth of required knowledge in a few specific areas is high.

One further word about environmental factors in development and decision processes. They are often the most important factors in any project. The final product, process, or service developed must be as robust as possible to all such influences. In the above technical institute example, hopefully the Ministry of Education periodically reviews the project and its to-date findings with both the prime minister and the parliament, so that there are no "last minute surprises" and "executive displeasures" with the process and stage-by-stage decisions. Even in relatively open and flexible democracies or businesses, these can be major hindrances to the project. In relatively closed and rigid socio-political climates, the repercussions for both the development and the development team can be somewhat harsher. The reader is left to determine what those repercussions can be on a case-by-case basis.

It is possible that many readers might desire some clarification as to why the recipients even of public services in this document are called "customers" and "end users", and why people who are not direct "customers" but who are effected indirectly are included in these categories. Anything that is used by the public, that uses up public resources, or that creates new public situations and issues effects more than just the initial recipient. One oft-heard critique of governments, businesses, and even NGOs is that their services, processes, and products are too often not designed with the recipient or the public in mind. Governments and businesses both have responsibilities to the people who pay their wages and grant them authority through taxes, votes, investments, or purchase prices. Not only do they have no right to adversely effect members of the public, governments and businesses don't really have a right to sustain known and easily curable inefficiencies. Similarly, NGOs should strive to always ensure they maximize benefit to their intended beneficiaries, and at a minimum have a responsibility to honor the intentions of their donors and coworkers.

It must never be forgotten by any organization that its decisions can trigger long lasting repercussions for all involved, directly and indirectly. Therefore, development teams should always consider anyone who their work touches directly as an "end-used" or "customer". Those who are affected indirectly should be considered a fellow "customer" at minimum.

Typically, the question of whether or not to replace an item or a system is at its most fundamental level a minimization or maximization question. What option do I choose to minimize my costs? What option will give the greatest overall value to all affects parties? The first question is primarily a financial analysis question. The second one is more of a system development type question. The challenge with replacement studies is that often, due to age, physical deterioration, environmental uncertainties, etc., the decision to replace an entire system can basically put the decision makers' backs to the wall. They might have no choice but to start from scratch with an all-new system, such as a plant investment, or a telecommunications system, as the original is too far gone to convince anyone to rehabilitate it. In least developed countries the constraint of having decrepit, totally useless systems needing replacement smacks headfirst against an equally harsh constraint.... the lack of any discretionary funds. This situation makes the need for thorough development and decision processes quite important. The smaller the safety net, the greater the need for certainty and the longer the time desired between tight rope walks.

One challenge that the developer of any system has is to try and make their system as flexible to the environment and to circumstance as it can be. In engineering terms, this is called a "robust" system. A robust system is one that performs its desired task as properly and consistently as possible even in light of large changes in its inputs and the overall environment. A government and the public it represents can view a robust system as one that will maximize the benefit it returns to the public no matter what kind of macro-economic and large socio-economic changes are occurring. An investor can see this as risk minimization - all investments are bets, the key is to make the odds of success and reward as predictable as possible. With respect to replacement studies, the developer of a system should always try to include maximum robustness as a decision metric. That way, the next replacement study can be made to be as far out into the future as possible, leaving the developer, the customer, and the public with the time and resources to deal with other matters, knowing that the most secure system feasible was put into place.

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

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

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

"Voice of the Customer" Requirements - Room One	Importance Ranking
Offer all major engineering disciplines, computer science, geology, and economics degrees.	10
Offer, at a minimum, both undergraduate and masters degrees.	10
Require microeconomics and macroeconomics classes for all graduates.	10
Basic computer and Internet skills are to be required for all graduates.	9
Financial incentives to help reduce "brain-drain" migration of the graduates should be used.	8
Preference in recruiting and hiring faculty should be given to those candidates who have technical industrial experience.	7
Offer process/manufacturing concentrations in each relevant engineering major.	7
All students must have internship semesters with technical or industrial organizations in the nation.	7
Require product or process design projects for all for all graduates.	6
Case studies of national and foreign companies and organizations are to be used in the curricula.	5
Students must work at the institute to help offset its costs.	4
All students must study French, English, or Portuguese.	3
Offer night and weekend courses.	3
Require research projects for all graduates.	3
Use all-new textbooks as often as possible.	1

Specific Requirements - Ranked		Total Weighted Importances
A	Offer mechanical, chemical, electrical, industrial, and civil/environ. engineering undergraduate degrees.	100
B	Offer geology and computer science undergraduate degrees.	100
C	Offer masters degrees in those departments with sizeable undergraduate enrollment, where budgetable.	100
E	Establish an economics department that will also teach micro - and macroeconomics to other majors.	100
F	Offer operating system, word processor, and spreadsheet training to all students and faculty.	90
H	Offer e-mail addresses and text e-mail access to all students and faculty.	90
I	Offer an income tax break for the first five years that an employed graduate stays in the country.	80
J	Technical and economic faculty job candidates who have prior experience of two or more years in technical industrial companies will be given preference in hiring.	70
K	Mechanical, chemical, and electrical engineering undergraduate degrees will have design/analysis concentrations, and concentrations in processing/manufacturing.	70
L	Technical and industrial businesses and government departments will be selected as partners to offer internships to students in the relevant majors.	70
D	Product or process design theses will be required for graduation from engineering and comp. sci. majors.	67
M	Pursue dual-degree programs with other universities intra- and extra-regionally to offer masters' and doctoral programs where the budget does not allow for them.	60
N	Analysis theses will be required for graduation from geology and economics majors.	60
G	All course curricula shall utilize technical and financial classwork examples and case studies focusing on both national and foreign companies and organizations.	50
O	Establish Internet and website authoring labs on campus.	45
P	All students are required to work for the institute on campus at least five hours per week each semester that they are enrolled.	40