DIFFERENT POINTS OF VIEW
The dichotomy between producer and user standards is
due to a difference in their definition of "success". Producers make
choices based on the goals of individual research projects or on the goals of
technology development. Users make choices based on corporate objectives and
the profit motive. Do not fool yourself into believing that non-profit and
government organizations do not think in terms of profit. It is just that their
units of measure are different from those of traditional businesses. Some
different units of profit measure might be:
a) # aircraft returning from high-risk missions
b) # poor credit risks not taken
c) # additional people housed
d) # additional bushels harvested
The standards dichotomy has results that are not
always good for either producer or user. It is important to remember that
funding usually comes from a user need for applications and solutions. Producer-oriented
projects do not always meet those needs. So, funding can dry up due to lack of
identifiable value in a project's resulting products. For the purposes of this
article, "product" refers to
whatever resulted from the research project. Research products include theory,
computational techniques, software/hardware, mathematical models, reports, and
papers. The result of the standards dichotomy can be fewer and smaller
opportunities for funding. But, this results in no research products for users,
no solutions to problems, and no new applications. This results in a loss of
market competitiveness. Note that this result affects both producers and users.
If the user is not competitive, there will be no continuance of the activity
that produces funding in the first place. Don't forget that the user provides
the producers' funding. It is interesting to contemplate the downward spiral
that results both on an individual business and on a national basis. One has to
think world-wide here since America competes with other nations. The bottom
line is that this downward spiral is not good for producers or users.
SIX MAJOR AREAS WHERE DICHOTOMY EXISTS
The author has observed six major areas where a
dichotomy exists between the business and personal standards of technology
producers and the needs of technology users. The six areas are:
1) education
2) language/hardware suites
3) communication with appropriate parties
4) approach to marketing
5) user need satisfaction
6) too early declaration of solution achievement
Each of these areas will be discussed below.
EDUCATION
Education should not be reoriented to training. There
is a great tendency for N-12 schools to attempt to prepare their students for
jobs that will not exist when they finally graduate from college. A great
mistake is to focus young students' attention on devices, such as computers, in
an attempt to "maximize the use of scarce teacher resources", to
"prepare students for the high‑tech world", or to "improve
eye-hand coordination." Lost in these efforts is the foundation needed for
new learning. Education is not the same thing as job training in some trade
craft. Teaching fundamentals is hard, compared to, for instance, teaching
someone to express simple ideas in some odd syntax such as used for computer
programming.
The focus of education should be on comprehension,
expression, and objective thinking, not on devices, such as computers. Schools
cannot renege on their responsibility to lay the foundation for future learning.
An early misfocus on devices causes three problems for students' later efforts
to engage effectively in the professional world:
1) they get a wrong impression of priorities
2) they know how
to do things but cannot determine what
things to do
3) they become untrainable since they do not have the background or mental flexibility to learn new concepts
and skills or
to adjust to changing environments and requirements
A particular danger exists for those of us who go on
to become computer professionals. It has been my personal experience that
computer people tend to focus on the computer and some technique or language as
central. This misfocus causes a poor employment environment. There are many
companies that do not hire people degreed in computers because of a perception
that such people focus on computers instead of, and sometimes in denial of,
corporate goals.
The dichotomy here is that technology producers tend
to focus on how to make the computer do things while technology users
tend to focus on what things to make the computer do. Producers are
concerned with technology itself while users are concerned with the goals to
which technology is applied. The lesson is that sustained research funding
results from a focus on user goals, not from a focus purely on technology or
"devices." Advancing an area
of technology or having the latest "device" is not necessarily the
same as meeting a technology user's requirements. Be careful not to let
mistaken priorities diminish your opportunities for sustained research funding.
LANGUAGE/HARDWARE SUITES
Always deliver for the user's environment. Language
and hardware suites that are good for research and technology development are
not necessarily good for implementation in a user environment. One big mistake
is to deliver your product on esoteric hardware written in an esoteric language
and then claim the product can be translated. While considering the various
options, it is not useful to insist that the contract does not specify a
language/hardware suite.
An example is DOD sometimes needing Ada for embedded
systems and development projects being written in Lisp, Prolog, C, or some
other non-Ada language. Users know that translation is a high-risk affair and
very costly. Examples abound of successful research projects that did not make
it to implementation because of the high risk and cost of translating to the
user environment.
Lack of implementation causes loss of research
credibility. The money available to research and development increases the
closer you get to implementation. Figure
1 is a notional illustration of this concept. In the
government environment at least, the funding available to basic research does
not approach that available to implementation research. It is important to pass
from one phase of research to another to take advantage of the funding curve. A
major issue in passing from one phase of research to another is the manner of
implementation. If the implementation is not fit for the user environment, it
stands less chance to pass through the various phases (basic, applied,
implementation).
Figure
1. Availability of research funding
As you can see, the dichotomy of producer suites vs.
user environments can cause funding loss. Developers who try to jump from one
prototyping contract to another have taken a short‑term view that
prevents them from grasping the golden ring of research funding. Consistent
funding is achievable if they take a longer view and deliver quality products
that encourage follow‑on work.
COMMUNICATION WITH APPROPRIATE PARTIES
Always put the user in touch with the product,
remembering that you are communicating with users and not with your peer group.
In this, you must forget self-pride and write to develop the users'
understanding of the background and employment of the product. Make sure you
relate the product to the objectives of the user. Who funds your projects? Be honest, is it your peers or the user
community? You must maintain credibility
with those who fund the project. Writing for peers is beneficial but only after
the user has been taken care of.
The dichotomy here is caused by the ego being at
variance with the users' need for understandable information. This author knows
of too many researchers who take pride in writing material no one can
understand. This is useless and leads ultimately to funding loss. Control over
pride is essential for successful communication between technology producers
and their users.
You should always provide something understandable in
the way of documentation despite what the contract calls for. Remember to talk
outside peer group boundaries. Discuss related mathematics, putting the
equations in a form useful to the next phase of research or application. Explain
the implications of the research results, using language others can understand.
Be conscious of and avoid terminology that is obscure to those in a broader
audience. Explain ideas not usually grasped intuitively by those outside the
specific research area.
Know that technology users are intelligent but their
focus is on applications and not on the details familiar to technology
producers. Users are often just as surprised at the lack of producers'
application knowledge as producers are of users' lack of detailed research
knowledge.
Here is an example of what can happen when these
lessons are forgotten. A research group had worked very hard on a difficult
project that permitted them to deliver sophisticated hardware to their funder's
implementation laboratory. However, the hardware was accompanied by
documentation of only a page or two. Neither the documentation nor the data
plate on the equipment had the research group's name, address, phone, or the
equipment's purpose. Time passed and a new implementation team took over the
project. They could not discover the purpose nor the operation of the delivered
hardware. Ultimately, the equipment was discarded. The user lost money. The
producer lost opportunity. This was not a good situation for either group.
Be keenly aware that understandability affects
funding. If the product cannot be understood, it will not be used. If the
product is not used, no value is perceived. If value is not perceived, expect
follow-on funding to be zeroed.
APPROACH TO MARKETING
The big trick here is to avoid the
over-sell/under-deliver trap while ensuring continued funding. In order to get
new work funded, the developer over-exposes (over-promises) the work's
potential. But, in the glare of reality and short timing, the potential is not
realized. At this point, the sponsor gets frustrated and cuts or stops funding.
Developers should not forget that sponsors have deadlines and quotas to meet. In
the author's experience, it is better to expose potential only in so far as it
can be realized in a given period of time. Do not promise the moon and deliver
an ant hill.
The over-sell/under-deliver trap is laid in a manner
illustrated by Figure
2. This figure shows that expectations of technical
achievement rarely meet reality. A problem is that developers' tend not to
recognize the reality that all technologies have a limit to their usefulness,
to the number and types of problems that they can solve. Other missed points
include realities such as limited funding and equipment as well the emotional
momentum of past methods.
Figure
2. Laying the over-sell/under-deliver trap
Generally, technology producers tend to over-expose
the potential of new technology thus achieving unreliable funding. Users tend
to react better to an under-exposure of the potential of new technology. This
reaction often ensures a block of reliable funding. Let's look at what happens
in a little more detail and see what can be done.
First, there are three terms that need definition. These
terms will be used in Figure
3 and Figure
4.
1) exposed potential: what is promised as the achievability of the research project in terms of user objective
satisfaction
2) realizable potential: what is actually
achievable
3) expected funding line: the level of funding expected from over-sell/under-deliver and under-sell/over-deliver
marketing strategies
Figure
3 shows the over-sell/under-deliver funding expectation.
Note that funding is very choppy because user expectations are far from
satisfied, causing uncertainty about the exposed, but unrealized, potential. Just
as the development project gets to the point when something great could be
accomplished, the user gets frustrated and cuts the funding back to levels too
low to support significant advancement. The result is unhappy producers and
users. Since users provide funding, this is a situation to avoid.
Figure
3. Expected
over-sell/under-deliver funding line
Figure
4 shows the under-sell/over-deliver funding expectation.
This is the author's preferred approach to R&D marketing. A project's
potential should never be exposed to the level that it can be realized. In this
way, user expectations are always exceeded. This keeps the funding at a level
appropriate to the realizable potential. Funding tends to be available when
most needed and not spent too early in the research program.
Figure
4. Expected under-sell/over-deliver funding line
USER NEED SATISFACTION
Always replace 100% solutions with 100%+ since new
technology must fulfill 100% of the old requirement plus a meaningful
percentage of future requirements. It is not wise to attempt to introduce a new
technology that forces users to give up past capabilities. The user need
satisfaction dichotomy derives from the producers' desire to create something
new vs. the users' attempts to maintain current capability while positioning to
provide for future requirements.
Figure
5 illustrates an example. Technical standards used by
most developers to judge some learn-by-example methods measures time and
resources taken to learn 90-95% of the training set. Reaching 90% accuracy is
considered a success. Training to 100% accuracy is considered over-trained,
causing loss of generality. This standard does not address what to do with the
other 5-10% if each example in the training set represents an important aspect
of the actual task specified by the user. These aspects cannot be incorrectly
dealt with by a generalization heuristic due to the criticality of the
situations represented.
Figure
5. Learn-by-example training of adaptive systems
The general theme is that users must continue solving
present problems while ensuring total solutions to future problems. Producers
must step up to the necessary technology merge for total solution to take
place, not deliver a partial solution and leave the rest to the users.
Another dimension of user need satisfaction is the
rate at which objectives are met, or the timing of objective satisfaction. This
is illustrated in Figure
6. Research credibility with users does not start to
grow until the user begins to be satisfied with project results. When users
have to wait too long for satisfaction, their wallets close. Whenever you start
a research project, whatever the contract calls for, ask yourself, "What
beneficial thing can I deliver to the user in the first week, month, 3
months? What short-term good can I do
for the user relative to the objectives?"
Of course you are laying plans and starting actions for long term
results but don't make the user wait until the end of the project to see some
good from the funding. The end may come sooner than you think. Always have
something to show for the resources used. Some credibility exists due to past reputations
but don't try to ride too long on your wake. Credibility (and, thus, funding)
goes quickly to zero if results are not forthcoming. Remember, users fund
results, not brains. Smart people who get no results are legend. Don't let
yourself be typecast with this lost crowd.
Figure
6. Credibility increases as objectives are met
TOO EARLY DECLARATION OF SOLUTION ACHIEVEMENT
Producers tend to declare solution achievement at the
theoretical level whereas users need solutions at the practical level. Thus,
producers tend to achieve solution satisfaction long before users do. To avoid
this trap, remember that solutions must be:
a) understandable
b) usable
c) available
d) accessible
c)
supportable
d) repairable
e) maintainable
f) updatable
Producers must actively work on these elements when
dealing with users or no solution exists from the application point of view. To
get the right focus, it is necessary for the producer to overcome the
dichotomies discussed in this article.
CLOSING
This article has not been about technology push vs.
requirements pull. In actual practice, technology's advancement occurs best
when there is a balance between push and pull. Users and producers, working by
themselves, tend to cause an imbalance. Producers should push technology to
give users new opportunities. Users should challenge producers to develop the
technology necessary for meeting complex objectives.
By being knowledgeable about how users think, it is
possible to achieve sustained research funding. To increase the chances of
sustained research funding it is necessary to know your user, know your user's
goals, and to make sure your research products meet your user's goals. In this
way, value is perceived and the resources needed for future technology
advancement are more likely to be available.