Quality
Function Deployment (QFD) in the BOCOMO projects:
Basemap
It has been almost universally accepted nowadays that key to
success in introducing new technology, as well as in business
in general, is in understanding and meeting customer needs.
BOCOMO projects undertaken by ICREST under the Raytheon's Synergy
initiative represent a good example of interactive assessment
of user requirements through a structured approach utilizing
the elements of the Quality Function Deployment (QFD) methodology.
The intent was to use the QFD methodology for further analysis
of processes enhancing the acceptance of remote sensing technology
by a target group - local governmental entities. 1. QFD: background
In terms of age, QFD is a relatively young technique. Its first
use was reported in Japan in the late 60s, at the Kobe Shipyard.
From there, the applications were further developed in various
industries. In the mid 80s, Dr. Donald Clausing brought information
on QFD to Xerox. From there a number of organizations have promoted
and taught how to utilize QFD, the two most prominent organizations
being GOAL/QPC and the American Supplier Institute (ASI).
Nowadays QFD continues to attract a lot of attention in several
industries. It is increasingly being recognized as an excellent
means of ensuring that the "Voice of the Customer" directs
the efforts of the complete organization. This usually results
in providing products and services which are better accepted
in the marketplace since they more accurately reflect what the
customer is willing to buy.
QFD is a systematic approach mapping the customer's needs into
definable and measurable product and process parameters, using
matrices and other quantitative and qualitative techniques.
The thing that makes QFD unique is that the primary focus is
the customer requirements. The process is driven by what
the customer wants, not by innovations in technology. It tends
to look beyond the usual customer feedback and attempts to
define
the requirements in a set of basic needs, which are compared
to relevant technical information. 2. The Core QFD Matrix
The basic tool of analyzing customer requirements and deploying
them into product or service is
the Core QFD matrix. This matrix is a fairly flexible approach
to implementing QFD that can be configured in different ways
depending upon the purpose or application of the matrix. In fact,
one of the keys to successful implementation of QFD is to adapt
the basic matrices and procedures to the product, process, and
project at hand. Working with the BOCOMO research teams we have
utilized a combination GOAL/QPC call the A-1 matrix and what
ASI calls the customer requirements matrix as an element of the "House
of Quality" concept. (Fig.1, p.7).
On the left side are customer needs ("Whats") reflecting
the "voice of the customer", what the customer wants
in the product. The top of the matrix shows technical characteristics
("Hows") that a research team can control in order
to satisfy the customer's requirements. The right side of the
matrix illustrates evaluation and prioritization of Whats and
assigns the Importance Weight and the Relative Weight for each
requirement. The body of the matrix shows relationship correlations
between what the customer wants from the product and how a project
team can meet those requirements. Relationships within this section
are defined using a strong ( ), medium ( ), weak ( ), or none
(blank cell) scale. The peak of the matrix (the "Roof")
is used to identify the interactions between different Hows and
the relationships are rated as strong positive ( ), weak positive(
), weak negative ( ), strong negative ( ), and none. The bottom
of the matrix is the prioritized and weighted technical requirements.
It identifies the requirements that are the most critical for
success, which is illustrated through a bar chart to provide
quick analysis of the key technical requirements. This is followed
by a concept evaluation section in which different system alternatives
are compared for determination of how well technical requirements
are met.
3.
Customer needs (Whats): the "Voice of the Customer"
QFD relies upon the principle of listening to the "voice
of the customer", a term used to describe what the customer
desires from a product or service. There are different interactive
techniques used to obtain this information. In the basemap project
we went through three stages, each time increasing the level
of detail and specificity of the customer needs: initial brainstorming
sessions with all the users and project teams; focus groups'
meetings with users interested in a specific application; phone
and face to face interviews to verify the list of needs for completeness.
As a result, a list of the following customer needs was developed:
1) To have a high-quality base map;
2) Maintenance: locally maintainable;
3) Maintenance: ability to modify if needed; ;
4) Currentness/timeliness of data;
5) Easy to use/access;
6) Cost-effective;
7) Seamless;
8) Providing opportunity for new applications/uses;
9) Group consensus on base;
10) Aesthetic/looks good;
11) Providing the opportunity to create derivative products;
12) Success.
It should be noted that not all of these needs are "spokens",
i.e. explicitly stated customer expectations. Some of them are "expecters",
the qualities a customer expects without telling, for example,
#1 and #12 in the list above. Others can be classified as "exciters" (also
referred to as "excitement" or "wow" factors),
qualities a customer may not be aware of, but when they are present
customers feel extremely pleased (#6, #8, #11).
The next step was to ask the customers to prioritize the list
by assigning a numeric value (degree of importance) to each need.
Also, the users were asked to assess their current level of meeting
this or that need. Both ranking exercises were done through e-mail
questionnaires using a scale from 1 to 5. That helped us to evaluate
their current situation and determine the anticipated level in
order to see how much improvement is needed or can be provided
with the new product. The improvement ratio was obtained by dividing
the anticipated level value by the current level rating. The
next step was to determine the importance weight of the customer
needs. It was calculated by multiplying the value of degree of
importance times the value of improvement ratio. Then importance
weights were normalized into relative weights yielding percentages
graphically represented in a bar chart. The process helped to
determine which needs were the drivers for the technological
development: besides two "expecters" (#1 - "to
have a high-quality base map" and #12 - "success"),
the top four customer needs included two "spokens" (#4
- "currentness/timeliness of data" and #9 - "group
consensus on base"). The values of relative weights identified
for customer needs will be used in prioritizing technical solutions,
as will be shown below.
4. Technical requirements (Hows) and their relationship with
customer needs (Whats)
Basically, Hows are ways of achieving Whats. By answering the
question: "What can we control that allows us to meet our
customers' objectives?" the project team identified twelve
technical requirements including technical specifications/controls
as well as service (training/education) and operational (implementation
plan) elements. The next step was to fill out the relationship
(central) area of the matrix by correlating technical requirements
to individual customer needs in order to determine strength of
relationship and impact on the need. Four symbolic and numeric
measures were utilized:
•
Strong relationship: = 9;
•
Moderate relationship: = 3;
•
Weak relationship: = 1;
•
No relationship: blank cell = 0.
The selection of the numeric values 9/3/1/0 is a relative weighting
so that strong correlations are valued heavily while correlations
that are weak or nonexistent carry little value. This system,
as opposed to 5/3/1/0 or 4/2/1/0, is believed to better identify
the drivers to the system providing greater separation between
the technical solutions. After completion of the relationship
area of the matrix, it was checked for completeness and adequacy.
For example, a blank column for a technical requirement could
indicate either a technical requirement that fulfills no customer
needs, or, possibly, a perceived need for a technical requirement
but the customer need had not been properly identified. In our
case, there were no blank columns, nor rows in the matrix.
The next step was to prioritize technical requirements by determining
the importance weight and the relative weight of the technical
requirements. The importance weight was calculated as the sum
of the value of relationship (9, 3, or 1) multiplied by the relative
weight of the customer need. For example, the importance weight
of the first column "xy positional accuracy" was calculated
as follows: (9x14.2)+(1x4.2)+(1x3.7)+(9x6.4)+(1x8.5)+(9x14.2)+(1x8.5)+(9x12)=
446. The relative weight represented a percentage of an individual
weight of the total weight:
Importance weight divided by the total weight multiplied by 100.
After determining the relative weights of the technical requirements
we could identify the key technical solutions that could help
satisfy the customer needs. The bar graph made it easy to see
that three technical requirements - "co-registration: vector", "spatial
resolution", and "xy positional accuracy" - ranked
higher than the rest of requirements.
The highest ranking "co-registration: vector" reflects
the issue of positional accuracy of the existing line-work within
the vector data base and presents a major obstacle to the integration
of remotely sensed data into existing GIS data base structures.
Implementing this requirement, the research team developed a
process and toolkit to aid local governments in building a singular
base map to which the vector data could be migrated while maintaining
the integrity of the relative positional accuracy of the vector
line-work.
Interestingly, and not so obviously, the second highest ranking "trio" consisted
of requirements-counterparts to the top three: "co-registration:
IKONOS", "temporal resolution", and "edge
matching". The sum of relative weights of these six highest
ranking requirements showed that they accounted for 75% of the
total. Despite the fact that the other requirements were not
to be ignored, this implied that focusing on these parameters
only would help meet 75% of the customer's needs. This led us
to consider them "drivers" on the technical side and
allowed further analysis on how different alternative map products
(namely, traditional paper maps based on aerial photography,
DOQQs, and a map based on high resolution satellite imagery)
fulfilled these "winning" requirements. Quantitative
comparison of values in the lowest (Concept evaluation) section
of the matrix, conducted in the same way as the calculation of
relative weights, revealed that satellite-derived basemap scored
379.5 points, DOQQs - 231.1 points, and paper map scored 182.7
points. The calculation illustrated and quantified the advantage
of satellite derived data over alternative methods.
The "roof" of the matrix shows correlations among
the technical requirements themselves based on the assumption
that focus on increasing performance of a certain technical area
can have both positive and negative impacts on other technical
requirements. A positive relationship indicates that two Hows
may have synergy, while a negative relationship indicates that
two Hows may have an adverse effect on each other. In the case
of basemap, for example, the following technical requirements
were identified as having strong positive relationships: "xy
positional accuracy" and "edge matching", "GPS
reference/control" and "spatial resolution", etc.
On the other hand, "spatial resolution" and "Mr.SID/compression" were
assigned a strong negative relationship, because the increased
size of a high-resolution data file has an adverse effect on
the compression capabilities of software.
5. Conclusions
The important point in gathering data for the QFD activity was
to understand the needs of the customer fully involving him into
the process and making him a part of the research team. Supporting
techniques in developing a Core QFD matrix included brainstorming,
focus group discussions, questionnaires, and interviews. These
methods allowed to develop and organize information through a
structured process and provide visualization of relationships
at various detail levels. Most importantly, the QFD exercise
provided the research team with, first, a prioritized list of
what the customers wanted to see in the product, and, second,
a prioritized list of technical parameters that the project team
could control to satisfy the customer requirements.
Quantitative analysis of customer needs and technical requirements
allowed to evaluate the role high resolution satellite imagery,
in comparison with conventional methods, could play in creating
a high quality basemap for local planners and managers.
Fig.1. The Core QFD Matrix: Basemap.
|
