The Ten Common Myths of I.T.

"A company runs on information, not data."
- Bryce's Law

INTRODUCTION

You've heard them all before. They particularly arise whenever
quality work is required or when organization and management control
is imposed. Of course, I'm talking about the ten common myths of
I.T. Ten common rationalizations people in the Information
Technology world turn to whenever their authority or professionalism
is challenged. They are neither new or limited to a specific
geographical location. They have been around as long as the modern
computer and they transcend all cultural and industrial boundaries. What's
worse, they have proven to be effective.

The following is the ten most popular myths in the field. Obviously, it
is not all inclusive. It is simply the ten most commonly used:

OUR PROBLEMS ARE UNIQUE WE NEVER SEEM TO HAVE ENOUGH TIME TO DO THINGS RIGHT YOU ARE STIFLING OUR CREATIVITY SYSTEM DESIGN IS AN ART FORM TECHNOLOGY WILL SOLVE OUR PROBLEMS A DBMS IS A PREREQUISITE FOR DATA BASE THERE IS AN INFINITE AMOUNT OF DATA IN AN ORGANIZATION OUR COMPANY RUNS ON DATA USERS OWN THE DATA USERS DON'T KNOW WHAT THEY WANT

Let's look past the facade of each of these for a moment and
see what they really mean.

"OUR PROBLEMS ARE UNIQUE"

This is perhaps the most popular of the myths and is probably
used to pacify the ego of I.T. Management. I discovered it
several years ago when I happened to do some consulting for three
separate companies from the United States, Japan and Brazil. In all
three instances, the I.T. Managers insisted their problems were
unique to their company. They pointed at the overwhelming pressure
they operated under, uncooperative users, insensitive management,
and some cultural constraints. The parallelism was incredible. Here
were three separate companies, geographically separated by thousands
of miles, all of which describing the same problems, yet viewing
themselves as unique.

In studying this further, I discovered most companies share
the same problems, such as:

A. A substantial backlog of user requests (three to five years seems
to be the norm).

B. Poor communications internally within the I.T. staff
and externally with end-users.

C. Project cost overruns and slipped schedules.

D. Employee dependencies to maintain and support systems.

E. Hardware/Software dependencies; systems are tied too closely
to a particular vendor, making upgrading difficult.

F. Redundant data throughout an organization (we know of one state
government who conservatively estimated NET-PAY is calculated
at least 100 different ways).

G. Lack of adequate documentation (thus providing job security for
the staff).

H. High staff turnover.

I. Design inconsistencies.

J. Systems personnel clash with data base personnel.

K. Information Systems do not meet users needs.

L. DBMS is used as nothing more than an elegant access method.

M. Data is tied too closely to applications, making change difficult.

Bottom-line, I.T. organizations suffer from low productivity
and poor performance. Inevitably they end up in a "fire-fighting" mode
of operation constantly patching problems. However, the problem here is
the chief fire-fighters are also the principal arsonists. It is
unfortunate the "fire-fighters" enjoy higher visibility than those
who work quietly in a methodical manner. This is a situation where the
guilty are promoted and the innocent are prosecuted.

Instead of imposing management discipline and control, I.T. managers
resign themselves to a life of chaos. It is no small wonder their average
tenure in office is less than three years.

"WE NEVER SEEM TO HAVE ENOUGH TIME TO DO THINGS RIGHT"

This implies "we have plenty of time to do things wrong." There
is an interesting relationship between the quality of a product
and the speed by which it is developed. This phenomenon is true of
any product being built.

The faster the delivery of a product, the greater the chances are
for inferior quality. The slower the delivery, the greater the chances
are for superior quality. Neither extreme is acceptable; an even balance
must be maintained to assure one doesn't have an adverse effect on
the other.

Instead of developing a long range plan that incorporates an information
strategy, management nurtures the problem by saying they need everything
"yesterday." Software vendors prey on companies like this by offering miracle
products (e.g., CASE, 4GL, program generators, etc.) promising to accelerate
development while producing quality results. Without the appropriate
management environment, they deliver neither and compound problems
further. These tools concentrate on efficiency, not effectiveness. Before
you can streamline your operation, you must first know what you are doing.

"YOU ARE STIFLING OUR CREATIVITY"

This scapegoat is a favorite among the "techy set." It is a defensive
expression that springs up whenever discipline or change is mentioned. What
is ironic is these same people do not hesitate to reorganize a user's
department. The hypocrisy is incredible. Systems people, who are supposed
to be the agents of change in an organization, are the most resistant to it.

"SYSTEM DESIGN IS AN ART FORM"

Closely related to the "stifling" myth is the view of system design
as an exotic art form. Most systems developers like to be viewed as
free-spirited souls who do not like to be encumbered with organization,
discipline and accountability. The fact is, many of these so-called
"Rembrandts" are nothing more lousy house painters. They hide behind
the mystique of their technology in the hopes it will conceal their
poor performance.

Systems design is a proven and teachable science. This is not to
suggest science lacks creativity. For example, there is considerable
creativity in the sciences of architecture, engineering, music, etc. Science
simply establishes the governing principals and rules to be observed
in your work.

"TECHNOLOGY WILL SOLVE OUR PROBLEMS"

This is more of a train of thought as opposed to an actual
expression. It is based on the belief that hardware and software will
correct all of the ills and ineffectiveness of the company. The belief
that technology, not management, will solve problems is just as prevalent
today as it was when the computer was first introduced.

It is fascinating to watch companies throw millions of dollars at
solving a problem through technology, yet balk at spending money for
management, a sort of "penny-wise and pound foolish" mentality. Corporate
management genuinely believes that I.T, management controls and tools can
be developed inexpensively, if not free.

To some companies, technology is purchased more as the latest
status symbol, as opposed to its practicality. It is purchased more
to "keep up with the Jones'" than anything else. What they don't realize
is the Jones' are in as much trouble as they are.

"A DBMS IS A PREREQUISITE FOR DATA BASE"

I remember meeting an I.T. Director from a large regional bank from the
U.S. southwest who insisted his company didn't have a data base. What he
meant to say was he didn't have a DBMS (Data Base Management System). With the
propagation of DBMS packages in the field, most companies now sincerely believe
a DBMS is a prerequisite for data base. Although DBMS software offers
tremendous leverage for file management, it is far from being a mandate for
data base.

All companies have a data base, some are managed, most are not. A data
base is nothing more than a collection of all of the data required to produce
information. Obviously, this definition transcends the computer. It is a
recognition that data is a resource which must be managed like any other
resource; e.g., money, people, materials, etc.

A DBMS offers great capability when managing data stored on mass storage
devices. But it must be realized that data is used throughout an entire
organization, in manual and computer applications, in a variety of files
(manual, tape, microfiche, disk, etc.). Data Base Administration
activities typically cover only the data used by a DBMS. What is necessary is
a higher level position that manages all of the data, regardless of where used
or how stored. The Data Management function should behave in a manner similar
to Materials Management, Financial Management, and Human Resource Management. This
is the Achilles' Heal for most I.T. organizations, the failure to recognize
data as a valuable and re-useable resource.

To compound problems further, even when DBMS technology is introduced
to a company, it is rarely used effectively. Instead of utilizing a DBMS
to share data among applications, most apply it as an access method only.

I conservatively estimate less than 5% of all I.T. organizations
in the world have successfully implemented a managed data base environment,
DBMS or not.

"THERE IS AN INFINITE AMOUNT OF DATA IN AN ORGANIZATION"

Some people would have you believe there is an inordinate number of
unique data elements used in an organization and to catalog and control
them is a mammoth undertaking (therefore, we shouldn't waste our time). Instead
of documenting a data element and re-using this intelligence,
people typically redefine data with each application. This leads to
inconsistent definitions and redundant work effort. But worst of all,
it makes implementing a change to a data element extremely complicated.

In reality, there is a finite number of data elements in any given
organization, probably in the neighborhood of 3,000 to 5,000. And although
it is no small effort to document the data, it is a wise investment in the
future. Once it is defined, a data element can be re-used in multiple
applications, which leads to a shared data base environment. Capturing this
intelligence must evolve over time with each application, it cannot be
captured over night.

"OUR COMPANY RUNS ON DATA"

This is one of the most naive statements in the business, one
rooted in ignorance. The person using this expression obviously
doesn't grasp the inherent differences between data and information. They
are not synonymous. The differences are simply too numerous to list
here but essentially Data by itself is meaningless; it is the representation
of a fact or an event. It is the raw material by which information is
produced. Contrary to this, Information is the intelligence or insight
gained from processing data to support specific business functions.

A company runs on information, not data. In fact, information is the
most important asset a company has. All actions and decisions are
predicated on information. Organizations progress when the impact of
good actions and decisions outweighs the impact of bad actions and
decisions. Information gives us the means to make these actions and
decisions.

Those who do not understand the differences between information and
data are probably the same people who do not understand the differences
between an information system and computer software.

"USERS OWN THE DATA"

This is a typical attitude found in companies who do not
understand the concept of managing data as a resource. In this
situation, data is jealously guarded by each user. As a
consequence, redundant files and applications are the norm. The
sooner you get past this stage, the better off your organization
will be.

Does the Controller "own" the money? Does the Human Resources Manager
"own" the employees? Does the Materials Manager "own" the parts?
Of course not; they simply administer the resource. A comparable
position to manage data resources must also be created.

"USERS DON'T KNOW WHAT THEY WANT"

Translation: "I don't know what I'm doing so I'll just keep hacking
away at the problem." This type of comment is a sign the person
is not properly trained in Systems Analysis. Users didn't get their job
by default; they must know a little bit about their end of the business,
otherwise they are not going to have it for long. The problem typically
stems from the analyst's inability to define business problems, specify
information requirements and to effectively communicate with the
user. Instead of asking how the user wants to view their screen,
try to understand their problem first. An elegant solution to the wrong
problem solves nothing. Only when the Systems Analyst can walk in the
moccasins of the user, does the analyst have the right to build a system
for the user.

CONCLUSION

You would think after forty years of promoting these myths,
we could invent some new ones that are a little more imaginative. The
fact they have survived this long is indicative that management is
still not facing up to their problems and are still baffled by
technical gobbledegook.