WRITING JOB FOR GENIOUS WRITER

HERE

Title is information requirement of Executives in the construction industry
Format is 1. Title Page
2. table of content
3. Introduction – (outline of the proposed Project about 1 
or 3 paragraph
4. Statement of problem
*What is the history of the problem
*Why is this problem interesting?
*When and Why does the problem occur?
*Is the problem already solved? What is done now?
*Are there any similar Systems or solutions to the one 
you propose? if so, reference and very briefly explain 
them
*Are there any possible improvements to current 
solutions?
5. Research Questions and/or Hypothesis (if any)
6. Objectives of the project
7. Significance of the project
8. Methodology
9. Scope of the study
10. organization of the remainder of the study
*Project details
*Implementation issues and challenges
*Deliverables
*Timeline
11. References
12. Appendixes

VERY IMP:

I need up to 4. Statement of the problem by tomorrow.

project work/Executive Information Requirements Getting It Right

Executive Information Requirements: Getting It Right
Author(s): James C. Wetherbe
Source: MIS Quarterly, Vol. 15, No. 1 (Mar., 1991), pp. 51-65
Published by: Management Information Systems Research Center, University of Minnesota
Stable URL: http://www.jstor.org/stable/249435 .
Accessed: 01/10/2013 20:16
By purchasing content from the publisher through the Service you agree to abide by the Terms and Conditions of Use, available
at
http://www.jstor.org/page/info/about/policies/terms.jsp. These Terms and Conditions of Use provide, in part, that this Service is
intended to enable your noncommercial use of the content. For other uses, please contact the publisher of the journal. Publisher
contact information may be obtained at
http://www.jstor.org/action/showPublisher?publisherCode=misrc.
Each copy of any part of the content transmitted through this Service must contain the same copyright notice that appears on
the screen or printed page of such transmission.
.
For more information regarding this Service, please contact service@jstor.org.
.
Management Information Systems Research Center, University of Minnesota is collaborating with JSTOR to
digitize, preserve and extend access to MIS Quarterly.
http://www.jstor.org
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=misrc

http://www.jstor.org/stable/249435?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp

http://www.jstor.org/action/showPublisher?publisherCode=misrc

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Executive Information
Requirements:
Getting It Right
By: James C. Wetherbe
MIS Research Center
Carlson School of Management
University of Minnesota
271 19th Avenue South
Minneapolis, Minnesota 55455
Abstract
Most managers spend half their time trying to get
the information they need, whether it be infor-
mally through meetings, phone conversations, or
reading, or formally through organizational
computer-based information. During this process
they have to sift through a great deal of useless
information, a situation commonly referred to as
“information overload.” With the proliferating
capabilities and plummeting cost of computers,
it seems relief should be in sight for weary
executives. Unfortunately, most information
systems-formal or informal-do not meet exec-
utive needs. Indeed, most new systems require
extensive revision (after they are supposedly
completed) to even partially fulfill needs. This is
a terrible loss. Most systems are expensive
enough to develop. They are even more expen-
sive to revise. As the pace of business acceler-
ates, decisions that could wait for weeks must
now be made in days, hours, or even minutes.
Failure to get executives the information they
need in a timely manner can result in lost oppor-
tunities or in a problem not being solved in time.
Increasingly, executives have little reaction time
to make decisions on pricing, product introduc-
tion, resource allocation, media inquiries,
response to competition, and mergers. They
need access to information without waiting
several weeks or months for a computer project.
Why can’t executives and system designers work
together to more correctly anticipate and deter-
mine information requirements? In this article,
four reasons information requirements are not
met are discussed, and four straightforward solu-
tions executives can use to solve this problem
are offered.
Keywords: Information requirements determina-
tion, prototyping, joint application
design, cross functional design
ACM Categories: D.2, H.2, H.4
Introduction
The new vice president of engineering for an
aerospace company noticed that he automatically
received 32 computer-generated reports each
month. He was having difficulty determining what
to do with most of them. Convinced his
predecessor received these reports for a good
reason and reluctant to admit his inability to find
meaning for them, he had an idea. If he found
out who the other managers were who also
received copies of these reports, he could subtly
inquire what they used them for and thereby
determine what he was “missing.”
He asked his assistant to get distribution lists for
all 32 reports. Within a week, the assistant
returned with the distribution lists.
“So who gets copies?” the vice president in-
quired
“Two people, you and me,” the assistant replied.
Startled, the vice president asked, “What do you
do with your copies?”
“They are just backup copies in case you lose
one of yours.”
By paying close attention during the next year,
the vice president determined that he only
needed four of the 32 reports. He also determined
there was some very important information he
was not getting. He discontinued the unneeded
28 reports, which resulted in immense apprecia-
tion from those who had to provide data to
generate them. He then began to focus on getting
the information he really needed. Over the next
year he became frustrated with the inability of the
information system department to meet his
requirements. The information system depart-
ment in turn became frustrated with his inabiliity
to “make up his mind” about the information he
needed. Because his requirements were in a con-
stant state of flux, the department had to con-
tinually revise the systems.
MIS Quarterly/March 1991 51
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
The preceding example is all too common and
represents a major cause for lost productivity
among executives and their computer people.
The most important task of an executive is
decision making. Outside of his or her intellect,
the most important resource an executive uses
is information. Yet time and again, executives
complain they are overloaded with irrelevant,
useless information, and they are unable to
obtain the information they need promptly.
The cost and time required to remedy a system
that fails to meet management’s needs can often
exceed the cost and time required to develop the
intitial system. High as it might be, the revision
cost might only be a fraction of the opportunity
cost of management making a bad decision
because it could not get needed information.
Consider the claims manager who cancelled the
insurance of a teenager because of a bad driving
record. Unknown to the claims manager, the
teenager was the son of the president of a large
corporate account. You can guess the rest of the
story.
Fortunately, executives can play a positive role
in ensuring that a new system meets their infor-
mation requirments. By understanding why
systems fail to meet requirements and the
remedial actions required, an executive can work
with systems analysts to get the system right.
This article covers the causes and solutions for
this problem. Discussed first are some fund-
amentals of information and decision making.
Next, a review is provided of the four common
mistakes that are made both by executives and
system designers when information systems are
designed. Finally, four techniques-cross-
functional systems, joint application design,
structured interviewing, and prototyping-are
presented as pragmatic, easy-to-implement solu-
tions for correctly determining executive informa-
tion requirements.
Managers and Information
One of the most important revelations about
managers and information that has come from
research and practice is that managers don’t
know what information they need.1 In a study
The inability of managers to recognize information needs was
pointed out by Russel Ackoff in 1967.
coordinated by the MIS Research Center at the
University of Minnesota, we found that 76 infor-
mation systems developed in 26 organizations all
required minor to major revisions after they were
completed to even approximate management’s
information requirements (Jenkins, et al., 1984).
The systems development process can be broad-
ly categorized into designing the right system and
implementing it right. Given an appropriate
design, most information systems departments
can successfully implement a system. The big
problem is correctly determining information re-
quirements and designing the right system.
How do most system analysts go about deter-
mining what information managers want from
their computer system? They do the obvious and
the logical. They ask, “What information do you
want from the new order processing (or whatever)
system?”
Unfortunately, managers usually do no know
what information they need. They give it their best
attempt, assuming these brilliant computer
wizards will sort things out. Several months and
millions of dollars later when the system is
delivered, managers quickly discover the system
does not give them the information they need.
Managers ask for changes, and the system
analyst goes into shock. Costs and time to
change the design of a system after it is complete
are 50 to 100 times higher than making those
same changes during systems design. This
sounds like an exaggeration, but it is not. If you
have had a custom-built house (or know someone
who has), you may be familiar with these
dynamics. For example, consider the cost of
adding a bathroom after the house is complete
versus the cost of adding a bathroom during the
blueprint or design stage. This explains why so
many needed revisions are never implemented.
Consequently, the resulting systems are a dis-
appointment. A disappointing system can range
from a system that partially fulfills management’s
requirements (with or without expensive re-
visions) to one that is totally abandoned, resulting
in a million dollar write-off.
For example, a major bank recently completed
a multimillion dollar project that tracked all of its
customers’ financial relationships with the in-
stitution. After the system was completed, it was
demonstrated to various management teams who
asked if the system would be able to provide
information it was not designed to provide. In
52 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
other words, managers wanted information that
had not been requested when the system was
designed the previous year. Though it would not
have been difficult to add the reporting
capabilities requested had they been identified
before systems development, to add them now
would delay the project more than a year and
double the cost of the system. Management was
so furious that the project, which at this point
represented over $40 million, was cancelled, with
many people losing their jobs.
Having been victims of managers’ inability to
properly define their information requirements,
most systems analysts go to Plan B-the “user
signoff.” This approach involves asking
managers what information they want from a
system and then requiring them to sign a docu-
ment aimed at contractually obligating them to
accept the system when they get it. User signoffs
have marginal political value when systems
analysts are battling with management about
system revisions, but they do not solve the
functional problem, which is that managers do
no know what information they need.
For example, in the banking example discussed
above, the managers signed off on the design.
However, once they realized the system would
not satisfy them, they blamed the responsible
system analysts for misleading them. Top
management legitimately claimed: “You
technical people should have protected us from
our lack of expertise in this area.” A user signoff
is a powerless piece of paper when matched
against the fury of top management.
Plan C, commonly used by systems analysts, is
to use the “catalog” approach to information re-
quirements determination. This appraoch in-
volves showing a manager a wide variety of
reports, perhaps requested by other managers
or available from a commercially available soft-
ware package. As the manager reviews these
reports he or she selects the ones believed to be
needed. This may seem like a good idea, but it
does not work. When you offer managers a lot
of reports, they request them whether they need
them or not.
In research projects we have offered cosmetically
impressive, but useless reports to managers and
have found that they have a high propensity to
take them (Benbasat, et al., 1977; Judd, et al.,
1981). For example, in one study, production
managers were offered 20 different reports. Eight
of these reports were deemed useful by a panel
of production experts. The remaining 12 reports
were useless, thrown in with the eight reports to
see if anyone would take them. Most managers
took all 20 reports. What they are generally do-
ing is playing it safe. Uncertain as to whether they
could use the information, they played it safe and
requested it. In practice, although the manager
requesting the information does not use it, the
manager who replaces him or her years later may
assume the information has some value. Conse-
quently, he or she may often be found staying
late at work, sifting through the useless reports,
asking the compelling question: “I wonder what
my predecessor was doing with this information
that I am missing?”
Years of this phenomenon results in information
overload episodes similar to the one described
in the beginning of this article.
Four fundamental mistakes have historically been
made in the process of determining what infor-
mation executives need. These mistakes are
viewing systems as functional instead of cross-
functional, interviewing managers individually in-
stead of jointly, asking the wrong questions
during the interview, and not allowing trial-and-
error in the detail design process.
Cross-Functional Systems
The first mistake that has historically been made
in determining information requirements for in-
formation systems is that most systems are
viewed as being functional as opposed to cross-
functional (Wetherbe, 1988). This perspective is
too narrow. For example, when developing a new
budgeting system, we tend to focus on what in-
formation is needed by the budget managers or
budgeting staff members. The problem is that
people other than budgeting staff make use of
budgeting information.
Virtually all managers need access to budget in-
formation. Unfortunately, if the budget depart-
ment is designing the system, the system carries
a very strong control orientation as opposed to
a general management reporting orientation. This
results in budgeting systems that end up much
like a banking statement. Most people use a
banking statement to simply reconcile whatever
MIS Quarterly/March 1991 53
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
they are using to track their personal finances,
whether they be on paper or a personal com-
puter. Similarly, many managers keep their
departmental budgets on a departmental com-
puter and simply reconcile them with the
“control” statement they receive from the budget
department. Due to this phenomenon, up to 60
percent of the data entered into personal com-
puters are keyed from reports generated from
other computers in the same organization.
For example, a marketing vice president for a
manufacturing company wanted to categorize
costs and revenue by salesperson, customer,
and product. The budgeting system only
allocated costs by project account number. A
project could involve more than one salesperson,
more than one customer, and more than one
product. Only through extensive data collecting
from the sales force and the use of spreadsheet
software could the information needed be
obtained.
Some would argue that the budgeting depart-
ment should go ahead and incorporate the
reporting needs of functional managers in the
development of a new budgeting system. But the
common argument against this would be that it
would increase the cost of developing the system.
The flaw in this logic is that the increase in costs
exists anyway because these fucntional
managers have to develop their own systems. In
the end, this costs more than if the systems were
developed across the board and shared.
As this marketing vice president said, “The
accounting department adds so much overhead
to marketing by wanting more and more data
categorized in ways to allow them to control and
audit us. I need information categorized in ways
to help us sell effectively and efficiently. The
systems designed by budgeting are not respon-
sive to my needs. Have you ever heard of a
company that was successful because it had the
best accounting in the world?”
To illustrate the need to develop systems cross-
functionally, consider a business process such
as order processing. To process orders, sales
people have to decide which customers to call
on, what to sell them, and what is available to
sell. Credit must decide which customers can
have credit and how much, which customers
need past-due notices, and which customers’
credit should be discontinued. The warehouse
must decide what and how much inventory to
stock, when to reorder, when to unload slow-
moving inventory, and which customers to
allocate limited inventory to. Shipping must
decide such things as what merchandise to send
to which customers, what orders can be shipped
together to save delivery costs, and when trucks
should depart. These decisions are summarized
in Table 1. In developing a new system, we
should provide information so that all decisions
can be improved.
For example, consider the last decision listed for
the warehouse department in Table 1-which
customers to allocate available inventory to. If the
warehouse has five orders but only enough
inventory to fill three, it must make a resource
allocation decision. Typically, this decision would
be made on a first-in/first-out (FIFO) basis. That
seems equitable and fair, given the information
they have available to them.
This could result in a terrible decision. What if
a customer who does a lot of business with the
company really needs this shipment promptly,
recently received an order late and was furious
about it, is paying a high profit margin on the
order, pays bills promptly, and a truck is routed
to deliver a shipment to another customer near-
by the same afternoon. But because a FIFO
decision was made, the inventory is allocated to
someone who hardly ever does business with the
company, to whom the order is not urgent, who
yields a low profit margin, does not pay bills on
time, and a truck is not going into the vicinity for
the next three weeks, during which time inven-
tory could have been re-stocked anyway.
In trying to improve the quality of the decision,
factors that should be considered include:
* How important is each customer to the
business?
* How promptly does each customer need
delivery of the order?
* What is the profitability of each order?
* What is the credit status of each customer?
* What is the shipping schedule for delivery to
each customer?
* Has the customer recently been upset
because a previous order was late?
Note that the information needed to improve the
decision making in the warehouse comes from
54 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Table 1. Decision Centers Involved In Order Processing
Decision Center Activity Examples of Major Decisions
Salespersons Selling Merchandise * Which major customers to call
* What to sell customers
* What is available to sell
Credit Department Accounts * Which customers to allow credit
Receivable * How much credit to allow
Management * Which customers need past-due notices
* Which customers’ credit should be
discontinued
Warehouse Inventory * What inventory to stock
Management * How much inventory to stock
When to reorder stock
* When to unload slow-moving
* Which customers to allocate available
inventory
Shipping Packing and * What merchandise to sell to what
Department Shipping Orders customers
* What orders can be shipped together to
save delivery cost
* When trucks should depart
outside the warehouse. For example, customer
need, importance, and profitability would come
from sales, credit worthiness would come from
credit, and shipping schedule would come from
shipping.
A very important concept of information manage-
ment, therefore, is that most of the information
needed to improve the decision making within a
function will come from outside of the function.
This is why it is so important for an organization
to share information if it wants to improve pro-
ductivity. When an organization learns to share
information cross-functionally, employees are
empowered to make better and more productive
decisions for the organization.
The bottom line is that in crder to develop a new
information system, it is necessary to be aware
of all functions that are touched by the informa-
tion system and be sensitive to their decision-
making requirements. Then a system can be
developed that allows information to flow cross-
functionally to improve decision making.
As straightforward as the concept of cross-
function systems is, most system analysts
attempting to develop them complain that
employees are very proprietary about their “func-
tional” information and are often unwilling to
participate in a system that will “share” informa-
tion. Recognizing that information is power,
employees are not interested in sharing power.
For example, sales representatives for a
manufacturing company were not allowed to
access customer credit status. Consequently
they would occasionally invest substantial effort
into landing a large order for a client only to have
it rejected because of credit/financing conditions.
Customer relations were damaged and sales
morale suffered as the sales force began to refer
to credit as the “sales prevention department.”
This attitude is totally dysfunctional. Since in-
formation is power, the idea is to empower
decision makers by giving them the best infor-
mation to make these type of decisions. An
organization that does not share information
cross-functionally ends up with the left hand not
knowing what the right hand is doing.
To solve the problem, top management needs to
use its leadership and influence to achieve cross-
functional design. When a new system is being
undertaken, those functions that are transcended
MIS Quarterly/March 1991 55
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
by the new system must have management
participation in the design.
Joint Application Design
The second mistake commonly made in the
determination of information requirements is that
the system design team usually interviews
managers individually instead of using a group
process, also known as joint application design.
The individual interveiwing process places
cognitive stress on a manager, stress that hinders
his or her ability to respond adequately to
questions.
Consider this scenario: A group of strangers
come into your office and ask you to tell 10 jokes.
Even though you probably know 10 good jokes,
you might have difficulty recalling them. Most
people would. Let’s change this scenario. What
if a group of you and your fellow managers within
the company are put together in a room and
asked to generate some good jokes. Very likely
you and your colleagues could generate 80, 90
maybe 100 jokes. Each manager would be
familiar with perhaps 80-90 percent of them. In
other words, each manager really knows a great
deal of jokes, but when asked to come up with
them off the top of one’s head, one would have
difficulty recalling them. The moral is that group
or collective experiences and memory are essen-
tial in recalling information. When people are
asked to tell a joke, they generally tell ones they
have heard recently. By themselves they cannot
remember many from the past. Similarly, when
managers are asked what information they need,
they generally mention things they needed
recently, not everything they need. Therefore,
one reason that we want the requirements deter-
mination to be done as a group or joint process
is so the memory of each manager can be pooled
to do a more thorough job of recalling key
requirements.
A second reason for a joint application design is
that different functional areas of an organization
have different agendas when it comes to de-
veloping a new information system. For example,
considering the order processing system por-
trayed in Table 1, each decision center would
likely emphasize different design criteria. Sales
may view the primary importance of order pro-
cessing as ensuring prompt and correct delivery
of orders to customers. Credit, on the other hand,
may view the agenda as primarily ensuring that
the company gets full payment for all orders.
Those responsible for inventory management
are, of course, interested in facilitating good
inventory mangement, reducing inventory costs,
etc., while those responsible for shipping are
interested in ensuring good routing of trucks to
minimize delivery costs. So if we were to think
of the purpose of order processing from a group
perspective, we would likely end up with a design
criteria that would focus on improving prompt,
correct delivery of orders to customers while
ensuring credit integrity and facilitating good
inventory management, and good routing and
scheduling of shipments.
It is difficult to achieve this overall perspective
if each manager is interviewed individually. A
case study illustrates the need for joint applica-
tion design from a cross-functional perspective.
A direct mail catalogue company was revising its
information systems. Prior to the cross-functional
design, the credit department viewed its primary
goal as ensuring payment from customers. Ideal
performance would be for all customers to make
all payments-that is, no credit losses. In an effort
to increase its performance in this area, the credit
department had continually requested more and
more information about customers, i.e., credit
references, credit bureau checks, etc., to the
point that credit costs were becoming excessive.
Two mistakes can be committed in making a
credit decision. The first is to give credit to people
who will not pay their bills, and the second is not
to give credit to people who would pay their bills.
After looking at the problem cross-functionally
with joint application design, the organization
determined that it was better off not doing any
credit checks at all. This rather counter-intuitive
conclusion was based upon two key under-
standings that were generated from the joint
application design. First, the company could send
catalogues of only low-priced items to first-time
customers. Customers who paid for what they
ordered could be upgraded to more expensive
catalogues. Those customers who did not pay
would, of course, be dropped from any future
mailings.
In this way, the company was not inferring
whether customers would pay from credit
reference material; they knew for a fact, based
on their own experience, which customers would
56 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
and would not pay. It turns out that their losses
from not receiving payment were less than what
doing all the credit checks were costing them. In
other words, the cost of merchandise not paid for
was the cost of determining whether someone
would pay. This information was not only more
accurate, but it was also less costly than doing
the traditional credit reference checking. If credit
information requirements had been determined
without considering the context of sales manage-
ment, this insight would not likely have been
achieved.
Furthermore, it turns out that people who would
generally be categorized as higher credit risks
have a greater propensity to purchase this
company’s catalogues. Conversely, people who
would be considered excellent credit risks tend
not to buy anything from their catalogues. This
means the compnay could send out a lot of
catalogues to people with excellent credit ratings
and seldom make a sale. Therefore, it would be
losing money by shipping catalogues that never
generate any revenue. The company would be
better off marketing to those people who would
be higher credit risks but not letting them buy
anything expensive until it was established that
the customer would, in fact, pay for things
ordered.
Without the perspective provided by a joint
application design, it would have been difficult
for credit to accept that credit checks were not
functional to the overall process of making sales
and processing orders. Therefore, when deter-
mining information requirements, all affected
functions should be represented in the same
room at the same time.
Structured Interview
The third mistake made in determining informa-
tion requirements is that the designers usually
ask the wrong question: “What information do
you need from the new system?” Though this is
the obvious question, it is not at all helpful to
managers attempting to determine what informa-
tion they need. Systems analysts assume
managers surely know what information they
need. The executive assumes the systems
analyst knows what he or she is doing. The
problem is that this technique is akin to a
psychoanalyst talking to a patient lying on a
couch and asking, “What type of therapy do you
need?” Or a salesperson being an order taker,
rather than a problem solver, who asks, “What
features do you want?” If patients or customers
don’t know how to look out for themselves, they
are unlikely to get satisfactory solutions.
A personal story illustrates this point: When I
moved to Minnesota, I purchased a home in the
country with sufficient land to require a tractor
mower. I set out to purchase a tractor mower, not
knowing much about tractor mowers, other than
that I wanted a Toro. (The dean of our business
school was the former chief executive officer of
Toro, and I wanted a Toro in my garage-just in
case.) Consider me a manager who needed to
solve a problem but didn’t know specifically what
his requirements were.
When I went into a dealership to purchase a
tractor mower, the salesperson would ask me
what I was looking for. I would say I was looking
for a Toro tractor mower. After that I would find
myself in trouble. The next question I would
typically be asked was what blade width I wanted.
This was not a question I was really prepared to
answer. When I told the salesperson this, I could
see him roll his eyes as if to say, “I hate these
idiots who don’t know what they’re doing.”
Next he would ask how much horsepower I
wanted. “How much can I get?” I would respond.
He would say “five to 18,” as he rolled his eyes
again. Then he would ask such questions as, “Do
you want wide tires, narrow tires, a rear bagger,
a side bagger, manual start or electric start?” It
turned out the tractor mower would cost between
$800-$2,800, depending on how it was con-
figured. Ideally, I would like not to over or under
buy. Once the salesperson realized I did not know
what I was doing, he would immediately start
pushing the $2,800 unit, suggesting I should go
first class. Mowing my yard and first class are not
two concepts I associate with one another.
Suspecting that I was being oversold, I would
go to other dealerships. Unfortunately, I en-
countered the same experience, time after time.
Finally, I went into a dealership where the
salesperson was not an order taker but a problem
solver. He did not ask what features I wanted on
the lawn mower. He asked other types of ques-
tions such as, “How big is your yard?” My yard
was about an acre. Next he asked, “How steep
is your yard?” I told him it had a gradual slope.
He next asked, “What is the terrain like?” I told
MIS Quarterly/March 1991 57
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
him it was natural, lumpy in spots. He wanted to
know if I had fences or trees. I replied yes, a fence
and about 80 trees. Next he wanted to known if
I wanted my wife to use the tractor mower. I said,
“Are you kidding? This is her anniversary
present!”
With that information, he walked over to a tractor
mower unit and said, “This is the one you need.”
I said, “How much?” He said, “Eighteen hun-
dred dollars.” Well, that was better than $2,800.
I asked him why this particular unit. He said,
“You have a large yard so you want the widest
blade. You need 12 horsepower to drive the
widest blade, but you do not need 18 horsepower
unless your yard is both big and steep. You want
wide tires to keep them from slipping into a rut,
tilting the blade deck and scalping the yard; you
want a rear bagger so you can mow around the
trees and mow by your fences one way one time
and the other way the next time so you do not
pack the grass; and you want electric start
because you’ve got delusions you are going to
get your wife to use it!”
Notice that what he did was extremely simple.
He asked indirect questions that backed into my
requirements. He never specifically asked what
features I wanted.
This use of indirect questions is the creative skill
of the problem solver in sales versus the order
taker. Problem solvers creatively determine how
to obtain answers to requirements through less
obvious, indirect questions. Those designing in-
formation systems need to do the same, and
executives should request they do so.
A straightforward, useful approach to interviewing
executives (instead of simply saying “what infor-
mation do you need?”) to determine information
requirements has been developed through
research done at the MIS Research Center at the
University of Minnesota (Wetherbe, 1988). The
technique is based upon three different require-
ment/determination methodologies, defined in
Table 2. By combining questions from these three
different methodologies, a comprehensive,
reliable determination of conceptual information
requirements can be achieved.
Before conducting the interview, an agreement
of the overall purpose of the business activity
must be established in a joint application design
fashion. For example, for the order processing
system discussed earlier, the objective of the
system could be to ensure prompt, correct
delivery of orders to customers, maintain credit
integrity, facilitate inventory management, and
ensure good shipment routing and scheduling.
Once this has been established, questions can
be asked that determine what information is
needed to ensure those objectives are ac-
complished. A basic model for the information
requirements interview is portrayed in Figure 1.
The notion is to focus on issues that “back into”
information requirements. The specific questions
asked are as follows:
Business systems planning (BSP)
(Source: IBM Corporation, 1984)
1. a. What are the major problems encountered
in accomplishing the purposes of the
organizational unit you manage?
For example, in an order processing system,
problems include being out of stock too often,
allocating limited inventory to the wrong
Table 2. Comprehensive Interview Approaches, Implementations, and Developers
Comprehensive Approach Information System Implementation Developers
Specify problems and The executive interview portion of IBM
decisions Business Systems Planning (BSP)
Specify critical factors Critical Success Factors (CSF) Rockart
Specify effectiveness Ends/Means Analysis (E/M analysis) Wetherbe and Davis
criteria for outputs and
efficiency criteria for
processes used to generate
outputs
58 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Problems Solutions– Information
BSP
Decisions _’- Information
_– Critical
Success Factors
—– Information
Ends- – Effectiveness —- Information
E/M
Means -.- Efficiency Information
Figure 1. Framework for Information Requirements Interview
customers, and sending off trucks unaware that
another order going to the same destination will
be arriving at the dock within an hour.
b. What are good solutions to those
problems?
For example, to solve the problem of being out
of stock too often requires better inventory
management. To solve the problem of incorrectly
allocating orders requires letting the warehouse
know the importance of customers and the im-
portance of orders to specific customers. It would
also be helpful to know customer credit status.
To solve the scheduling of truck departure
problems requires letting shipping know the
destination of orders that are being processed but
have not yet arrived at the shipping dock.
c. How can information play a role in any of
those solutions?
For example, to improve inventory management,
out-of-stock and below-minimum reporting could
be provided electronically. Also, an automatic
reordering system could be implemented. Elec-
tronic access to customer importance, impor-
tance of order, and credit status could allow the
warehouse to make appropriate allocation de-
cisions when inventory is limited. If the shipping
department has access to orders received and
in process, it can make better decisions over
routing and scheduling trucks.
Table 3a provides an illustration of a structured
interview using the problem/solution/information
interview format.
2. a. What are the major decisions associated
with your management responsibilities?
Major decisions for order processing include:
which customers to call on and what to sell them?
Credit for whom? How much? When to dis-
continue credit? What and how much inventory
to stock? When to reorder? How to allocate
limited inventory? How to schedule and route
trucks?
b. What improvements in information could
result in better decisions?
Table 3b provides an illustration of a structured
interview using the decision/information interview
format.
Critical success factors (CSF)
(Source: Rockart, 1979)
3. a. What are the critical success factors of the
organizational unit you manage? Most
managers have four to eight of these.
MIS Quarterly/March 1991 59
CSF
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Table 3a. Requirements Interview for Order-Processing System: BSP
Problems Solution Information
Out of stock too often Better inventory management Out-of-sotck, below-minimum
report; automatic reordering
of inventory
Ordering department often Let warehouse department Customer-importance rating
allocates limited inventory to know relative importance and and credit rating
the least important customers credit status of different
and/or customers who have customers
credit problems
Shipping department often Let shipping department Shipping destination of orders
sends off a truck, unaware know the destination of provided when orders receiv-
that another order going to orders that are being pro- ed from customers
the same destination will be cessed through credit and
coming to the dock within an warehouse
hour
Table 3b. Requirements Interview for Order-Processing System: BSP
Decision Information
Which customers to call on and what to sell Customer-order history; inventory available
them?
Credit for whom? How much? When to Credit rating; current status of account,
discontinue? payment history
What and how much inventory to stock? Inventory on hand; sales trends on inventory
items; market forecasts
When to reorder? Priority of order; importance of customer;
credit status of customer;
How to allocate limited inventory? shipping schedule
When to unload slow-moving inventory? Sales trends
Destination of ordered inventory? Customers’ addresses
What orders can be shipped together to save Shipping schedule and customers’ destina-
delivery costs? tion for orders awaiting shipment
For example, critical success factors for order
processing include: adequate inventory to fill
customer orders, prompt shipment of orders, high
percentage of customer payments made, and
vendors (suppliers) promptly filling reorders.
b. What information is needed to ensure that
critical success factors are under control?
For example, to determine if adequate inventory
is available, management would need summary
and exception reports on percentage of orders
filled on time. In addition to overall reports, they
should also be categorized by customer and
product. To determine if orders are being shipped
promptly, management would need to have
summary and exception reports on delivery
time-both overall reports and reports categor-
ized by customers.
Table 4 provides an illustration of the critical
success factor/information interview format.
60 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Table 4. Requirements Interview for Order-Processing System: CSF
Critical Success Factor Information
Adequate inventory to fill customer orders Percentage of orders filled on time-overall
and also categorized by customer and
product
Prompt shipment of orders Delivery time-overall and also categorized
by customer
High percentage of customer payments Delinquency report on non-paying customers
Vendors (suppliers) promptly fill reorders Exception report of vendor reorders not filled
on time
Ends/means (E/M) analysis
(Source: Wetherbe, 1988)
4. a. What is the end or good or service pro-
vided by the business process?
b. What makes these goods or servcies
effective to recipients or customers?
c. What information is needed to evaluate
that effectiveness?
Table 5a provides an illustration of the ends/ef-
fective/information interview format.
5. a. What are the key means or processes
used to generate or provide goods or
services?
For example, means for order processing include
processing orders, processing credit requests,
and making shipments.
b. What constitutes efficiency in the pro-
viding of these goods or services?
For example, efficiency for order processing
pertains to achieving low transaction costs for
orders and credit checks. It would also pertain
to minimizing shipment costs.
c. What information is needed to evaluate
that efficiency?
Examples of information needed to assess effi-
ciency include cost per transaction with historical
trends, cost per credit transaction with historical
trends, and shipment cost categorized by order,
customer, region, and revenue generated.
Table 5b provides an illustration of the means/ef-
ficiency/information format.
The method of using these three methodologies
as a basis for indirect questions for obtaining a
reasonably correct and complete set of informa-
tion requirements is both simple and powerful.
It is simple because it consists of simple com-
ponents that can be learned by an analyst and
a manager in a relatively short time. It is power-
ful because it is based on fundamental theories
of human information processing and human
strengths and limitations. It provides a compre-
hensive set of approaches that are additive in
their results.
The interview has a redundant “safety net” built
into it. For example, note that a problem iden-
tified in the first set of questions in the example
pertains to poor allocation of limited inventory to
customers (see Table 3a). The need to allocate
limited inventory was also identified as a decision
that must be made (see Table 3b). In other words,
if the concept of allocating limited inventory was
not recalled as a problem, it can still be identified
as a decision, and vice versa. This “safety net”
effect greatly increases the reliability of the struc-
tured interview.
Note that what is generated from the interview
is a profile of conceptual types of information
necessary to support an order processing
system. For example, the first item in the infor-
mation column in Table 3a says “Out-of-stock,
below minimum report.” This could be the title
of a screen or report. The next item in Table 3a
is “automatic reordering of inventory,” which is
a function needed from a new system.
At this point, we need to take these conceptual
ideas and progress to the stage of detail design.
MIS Quarterly/March 1991 61
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Table 5a. Requirements Interview for Order-Processing System: E/M Analysis
Ends Effective Information
Fill customer orders Customer orders delivered as Summary and exception
ordered, when expected, and reports on customer
as soon or sooner than deliveries; number of order
competition corrections made; com-
parative statistics on delivery
service vs. competition’s
Provide customer service Promptly provide credit to Customer credit status and
qualified customers payment history
Quick response to and reduc- Report of number and type of
tion of customer complaints complaints by customers and
average time to resolve
complaint
Customers are satisfied Customer attitudes toward
services perhaps determined
by customer surveys
Table 5b. Requirements Interview for Order-Processing System: E/M Analysis
Means Efficiency Information
Process orders Low transaction cost Cost per transaction with
historical trends
Process credit request Low transaction cost Cost per transaction with
historical trends
Make shipments Minimize shipment costs Ship cost categorized by
order, customer, region, and
revenue generated
This is where mistake number four is normally
made.
Prototyping
The fourth mistake that is typically made in re-
quirements determination is that managers are
not allowed to determine and refine their con-
ceptual requirements into detail information
requirements through trial and error. Detail re-
quirements refer to the specific screens or reports
that are generated by a system, as illustrated in
Figure 2.
Trial and error, or experiential learning, is an
important part of problem solving. For example,
people are using trial and error when they
* Try on clothes before they purchase them
* Test-drive cars
* Change their college major after a few courses
* Have several relationships before marriage
* Rearrange furniture several times when
decorating a room
* Put more than one nail hole in a wall when
hanging a picture
Trial and error is also a part of determining detail
information requirements. It can be incorporated
into the system design process through the use
of a prototype or mock-up of the system. Using
state-of-the-art technology, a prototype of a new
system can usually be constructed in a day to a
62 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
CUSTOMER
Sales Departmcnt –
Shipping Department
I Menu
Customer
Order
Shipment
. . ..
…. .,I
IflI”-
— .
\w-E
SALES DEPARTMENT MENU
PROFILE
ACCOUNT
CUSTOMER COMPLAINTS
SURVEY
INVOICES
AD HOC
– ORDER RECORD
ORDERS . ORDER SUMMARY
AD HOC
ITEM RECORD
ITEM ANALYSIS
INVENTORY ITEM BY CUSTOMER
BELOW MINIMUM DISPLAY
AD HOC
– SHIPMENT RECORO
cuSHIPMENTS -rc.—–SUMMARY SHIPMENTS = O R D E ORDER BY SHIPMENT
~ AD HOC
CUSTOMER RECORD DISPLAY ?
CUSTOMER PROFILE
CUSTOMER I [ PAGE 10 o 63 CREDIT RATING [H-CUSTOME
–
CUSTOMER NAME I DATE OF LAST SALE I
ADDRESS STREET [ AMOUNT OF LAST SALEI ]
CITY | I CURRENT BALANCE
STATE I ZIP I 1 TOTAL SALES FOR LAST MONTH
COUNTRY I OUARTER
PHONE [ 1 YEAR 1
SALES CONTACT 1
SALESPERSON NUMBER I
DATE OF LAST SALES CALL [ I
TEAM ACCT OPENED [ 1
Figure 2. From Conceptual to Detail Reporting Specification
couple of weeks, depending on the complexity
of the system (Wetherbe, 1988). As in manufac-
turing, much can be learned about final require-
ments through a prototype before “building the
new factory.” A model of prototyping is provided
in Figure 3.
Conceptual analysis through a structured inter-
view prior to the trial-and-error process can
substantially reduce the amount of time ex-
pended to resolve the solution. For example, in
the five preceding situations, the following
analysis, prior to trial and error, could save time:
1. A fashion consultant could narrow the trial-
and-error search for a new wardrobe by
asking questions about career, lifestyle,
budget, and taste, and by observing physical
characteristics. Stores and designs could be
suggested based upon the answers to these
questions, thereby saving search time.
2. A well-trained car salesperson could ask
qualifying questions (similar to those of the
fashion designer) to better suggest automotive
alternatives.
3. A career counselor, based upon interviewing,
could suggest majors for students.
4. A marriage counselor could use personality
and interest profiles to assist in determining
the compatibility of potential marriage
partners.
5. Interior decorators could use their analysis
techniques to approach a decorating solution
that could be refined by trial and error.
As in these examples, the structured interview
prior to a trial-and-error process reduces the time
necessary to determine detailed requirements.
Unfortunately, over the years, systems analyses
have not incorporated a learning, trial-and-error
process into systems design. Equally as trouble-
some is that they either agree to or have imposed
upon them by management a budget and
schedule for a new system before there is a
prototype. This is naive. If the schedule and
budget are set, the only thing left to maneuver
around is the content of the deliverable.
Accordingly, systems analyses often leave useful
MIS Quarterly/March 1991 63
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
Based upon information requirements inter-
view, develop initial database with reporting
abilities using high-level languages and
relational database. System should have
fixed and ad hoc reporting abilities
Revise prototype by:
* Adding data
* Changing data structure
* Enhancing input and output
capabilities
* Enhance software tools
Demonstrate prototype to users and have
them use it
No
Figure 3. Model of Prototyping
or even critical functionality out of a system in
an effort to stay within budget and on schedule.
Consider this analogy: Have you ever moved to
a new city where you had to purchase a new
home? Did you have a price in mind and a
desired date to move in before you began your
search? Were you able to keep to the original
price and schedule or did you need to adjust to
meet your requirements? Often you looked at
houses (prototyped) and saw the ones you really
wanted. What would have happened had you
forced someone to meet your housing re-
quirements within the original price and schedule
you started with?
Management should not let systems analysts
disappear after the initial concept for the system
is established. Management should be able to
observe and experience a prototype within two
to five days after being interviewed. This
prototype can then be shaped into a final design
within a few weeks.
Once management accepts the prototype, a
realistic schedule and budget can be established
for building the system. Although systems must
evolve over time and should be built with evolu-
tion in mind, a system that is initially “right” will
not need substantial immediate modifications.
Evolutionary change of such a system is
therefore much more manageable.
Conclusion
More correctly determining information re-
quirements is a key productivity issue, both for
systems and for managers who need better
information for decision making. Failure to get the
requirements “right the first time” wastes human
and economic resources. Management can
greatly enhance the correct determination of
information requirements by encouraging their
systems designers to use a cross-functional, joint
application design that involves input from all
key decision makers involved in the business
process. The conceptual requirements for a new
system can be determined by a structured inter-
64 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Information Requirements
view. Detail requirements can then be identified
through prototyping. Then the best source of
information-be it formal or informal-can be
determined.
References
Ackoff, R.L. “Management Misinformation
Systems,” Management Science, December
1967, pp. 147-56.
Benbasat, I. and Schroeder, R. G. “An Ex-
perimental Investigation of Some MIS Design
Variables,” MIS Quarterly (1:1), March 1977,
pp. 37-47.
IBM Corporation. Business Systems Planning,
Publication No. GE20-527, Revision 4, July
1984.
Jenkins, A., Naumann, D., and Wetherbe, J. C.
“Empirical Investigation: Systems Develop-
ment Practices and Results,” Information and
Management (7:2), April 1984, pp. 73-82.
Judd, P., Paddock, C., and Wetherbe, J.C. “Deci-
sion Impelling Differences: An Investigation of
Management by Exception Reporting,” Infor-
mation and Management (4:5), November
1981, pp. 259-267.
Rockart, J.F. “Chief Executives Define Their Own
Information Needs,” Harvard Business
Review, March-April 1979, pp. 81-93.
Weatherbe, J.C. Systems Analysis and Design,
West Publishing Company, St. Paul, MN,
1988.
About the Author
James C. Wetherbe is professor of management
information systems and director of the MIS
Research Center of the Carlson School of
Management at the University of Minnesota. He
is the author of 12 books in information manage-
ment and systems design. He has completed
extensive research and consulting in the area of
information systems development.
MIS Quarterly/March 1991 65
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 20:16:56 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Article Contents
p. 51
p. 52
p. 53
p. 54
p. 55
p. 56
p. 57
p. 58
p. 59
p. 60
p. 61
p. 62
p. 63
p. 64
p. 65
Issue Table of Contents
MIS Quarterly, Vol. 15, No. 1 (Mar., 1991), pp. i-iv+1-144
Volume Information
Front Matter [pp. i – i]
Editor’s Comments: Re-Engineering the Organization [pp. iii – iv]
Issues and Opinions
On End-User Computing Satisfaction [pp. 1 – 4]
The Measurement of End-User Computing Satisfaction: Theoretical and Methodological Issues [pp. 5 – 10]
Executive Overview [p. 12]
Application
Executive Information Systems: A Framework for Development and a Survey of Current Practices [pp. 13 – 30]
Executive Overview [p. 32]
Application
Applications of Global Information Technology: Key Issues for Management [pp. 33 – 49]
Executive Overview [p. 50]
Application
Executive Information Requirements: Getting It Right [pp. 51 – 65]
Executive Overview [p. 66]
Application
On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices [pp. 67 – 86]
Executive Overview [p. 88]
Application
Identification of Strategic Information Systems Opportunities: Applying and Comparing Two Methodologies [pp. 89 – 103]
Executive Overview [p. 104]
Theory and Research
Decisional Guidance for Computer-Based Decision Support [pp. 105 – 122]
Executive Overview [p. 124]
Theory and Research
Personal Computing: Toward a Conceptual Model of Utilization [pp. 125 – 143]

project work/Executive Information Systems A Framework for Development and a Survey of Current Practices

Executive Information Systems: A Framework for Development and a Survey of Current
Practices
Author(s): Hugh J. Watson, R. Kelly Rainer, Jr. and Chang E. Koh
Source: MIS Quarterly, Vol. 15, No. 1 (Mar., 1991), pp. 13-30
Published by: Management Information Systems Research Center, University of Minnesota
Stable URL: http://www.jstor.org/stable/249431 .
Accessed: 01/10/2013 21:45
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .
http://www.jstor.org/page/info/about/policies/terms.jsp
.
JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range of
content in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new forms
of scholarship. For more information about JSTOR, please contact support@jstor.org.
.
Management Information Systems Research Center, University of Minnesota is collaborating with JSTOR to
digitize, preserve and extend access to MIS Quarterly.
http://www.jstor.org
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=misrc

http://www.jstor.org/stable/249431?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Executive Information
Systems: A Framework
for Development and
a Survey of Current
Practices
By: Hugh J. Watson
Department of Management
University of Georgia
Athens, Georgia 30602
R. Kelly Rainer, Jr.
Management Department
Auburn University
Auburn, Alabama 36849
Chang E. Koh
Information Systems and
Operations Management
University of North Carolina,
Greensboro
Greensboro, North Carolina
27412
Abstract
Executive information systems (EIS) are now suc-
cessfully providing computer support for senior
executives in a growing number of organizations.
Previous attempts to support senior executives
are discussed with a focus on why these attempts
failed and what was learned that should be in-
corporated in future efforts. An EIS development
framework is presented that includes a structural
perspective of the elements and their interaction,
the development process, and the dialog be-
tween the user and the system. Survey data from
50 firms having an EIS are presented and
discussed in the context of the development
framework. While most of the findings confirm
conventional EIS wisdom, others are somewhat
surprising, such as the significant role that infor-
mation systems management often plays in in-
itiating the development of an EIS or serving as
its operational sponsor. The findings lead to ad-
ditional suggestions for EIS research oppor-
tunities, as well as predictions about the future
nature of EIS.
Keywords: Executive information systems, ex-
ecutive support systems, decision
support, systems development
ACM Categories: H.3.5, H.4.0., H.4.2, K.6.0
Introduction
The target audience for computer support in
organizations has evolved over the years. Clerical
workers were the first to be impacted as transac-
tion processing systems were automated in the
1950s and 1960s. At about the same time,
engineers gained access to computers and
started what is now recognized as end-user com-
puting. Management information systems (MIS)
appeared with much fanfare in the 1960s. While
some envisioned them as “central nervous
systems” for organizations, in practice they
largely expanded the reporting system for lower-
level managers. Office automation began two
decades ago with the introduction of word pro-
cessors for secretaries and continues to expand
today as a growing variety of support becomes
available for office workers. In the 1970s, deci-
sion support systems (DSS) provided assistance
for specific decision-making tasks. While DSSs
can be developed for and used by personnel
throughout the organization, they are most com-
monly employed by staff and middle and lower
managers. Among the latest developments are
expert systems, which capture the expertise of
highly trained, experienced professionals in
specific problem domains.
As the evolution of computer support for
organizational personnel is considered, one
group is conspicuously missing: the senior ex-
ecutives of a firm. They have not been omitted
by design, and in fact, previous advances were
originally thought to potentially serve them (e.g.,
MIS and DSS), but for a variety of reasons, little
support has been provided. This lack of support
is rapidly changing, however, as executive infor-
mation systems (EIS) or executive support
systems (ESS) are being developed in a grow-
ing number of firms (Main, 1989). International
Data Corporation, a market research firm,
predicts that the U.S. market for EIS is growing
at a compound annual rate of nearly 40 percent
and that expenditures for EIS software develop-
ment, including the purchase of software, custom
consulting, and in-house software development,
MIS Quarterly/March 1991 13
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
will grow to $350 million in 1992 (Alexander,
1989).
Even though EISs support an important clientele
and are becoming prevalent, little research has
been done about them. The available EIS
literature is case study or anecdotal in nature. In
order to learn more about current EIS practices,
we studied 50 firms that either have an EIS or
are well along in developing one. The findings
are presented in the context of a framework that
can be used to understand and guide EIS
development efforts.
The results of this study should be of interest to
practitioners who already have an EIS or are
planning to develop one. The findings provide
benchmarks against which individual company
experiences can be compared. The results also
should stimulate academicians to do further
research. Specific research questions raised by
this research are presented later.
The next section defines an EIS, lists EIS
characteristics, and distinguishes between EIS
and ESS. This is followed by discussion of the
failure of previous efforts to support executives.
Next, an EIS development framework is intro-
duced and the research methodology of the study
is described. Then, the findings of the survey are
discussed in the context of the framework. Final-
ly, conclusions are drawn from the study.
EIS Definition and
Characteristics
Researchers have used a variety of definitions
for EIS (Paller and Laska, 1990; Turban and Wat-
son, 1989). For our purposes, an EIS is defined
as a computerized system that provides ex-
ecutives with easy access to internal and exter-
nal information that is relevant to their critical
success factors. While a definition is useful, a
richer understanding is provided by describing
the characteristics of EIS. Research (Burkan,
1988; Friend, 1986; Kogan, 1986; Zmud, 1986)
shows that most executive information systems:
* are tailored to individual executive users;
* extract, filter, compress, and track critical data;
* provide online status access, trend analysis,
exception reporting, and “drill-down” (drill-
down allows the user to access supporting
detail or data that underlie summarized data);
* access and integrate a broad range of internal
and external data;
* are user-friendly and require minimal or no
training to use;
* are used directly by executives without in-
termediaries;
* present graphical, tabular, and/or textual infor-
mation.
The EIS and ESS terms are sometimes used in-
terchangeably. The term “executive support
system,” however, usually refers to a system with
a broader set of capabilities than an EIS (Rockart
and DeLong, 1988). Whereas the EIS term con-
notes providing information, the ESS term implies
other support capabilities in addition to informa-
tion. Consequently, we find it useful to concep-
tualize an ESS as including the following
capabilities:
* support for electronic communications (e.g., e-
mail, computer conferencing, and word pro-
cessing);
* data analysis capabilities (e.g., spreadsheets,
query languages, and decision support
systems);
* organizing tools (e.g., electronic calendars,
automated rolodex, and tickler files).
These additional capabilities are typically made
available as options on a system’s main menu
or by the ability to “hot key” the workstation in-
to a PC mode of operation.
The distinctions between an EIS and an ESS are
not particularly important for our purposes other
than to recognize that an ESS influences and in-
creases system requirements. For example,
many systems include e-mail; hence, e-mail soft-
ware and a keyboard must be available. The
materials provided here apply equally well to EIS
or ESS, even though the EIS term is used
throughout.
Why Previous Efforts Failed
There are many reasons why previous efforts to
bring computer support to senior executives have
failed. Understanding these reasons is important
14 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
because they provide insights into what problems
must be overcome if an EIS is to be successful.
One of the difficulties involves the executives
themselves. Many of today’s senior executives
missed the computer revolution. Consequently,
they may feel uncomfortable using computers,
have poor keyboarding skills, or believe that
“real” executives do not use computers.
Another difficulty involves the nature of executive
work. Previous studies provide a better
understanding of what senior executives do and
insights into how computer support must be
delivered (Isenberg, 1984; Kotter, 1982; Mintz-
berg, 1975). Executives’ busy schedules and
travel requirements are not amenable to long
training sessions, do not permit much uninter-
rupted time for system use, and do not allow a
system to be employed on a daily basis (Albala,
1988). The result is that senior executives are
unlikely to employ systems that require con-
siderable training and regular use to be learned
and remembered. Because senior executives
have ready access to staff personnel to fulfill their
requests for information, any system must prove
to be more responsive than a human (Rockart
and DeLong, 1988).
Another problem in providing computer support
includes technology that is difficult to use, at least
from most executives’ perspective. Powerful
workstations, improved micro-to-mainframe soft-
ware, high-quality color graphics, and touch-
screens are just some of the technological
developments that now make it possible to deliver
appealing systems to senior executives.
Finally, many previous systems have contained
little information of value to senior executives,
which is a problem related to a lack of understan-
ding of executive work. This lack was exacer-
bated by systems designers who often possessed
excellent technical knowledge but little business
knowledge (Reck and Hall, 1986). This condition
is improving as organizations recognize that
business skills and the ability to interact with
executives are critical.
Three broad guidelines for developing a suc-
cessful EIS can be gleaned from these failures.
First, the EIS must meet the information needs
of senior executives. Second, in order to do this,
the EIS must be developed by personnel with
both business and technical skills. Finally, the
EIS must be so easy to use that it might be con-
sidered to be “intuitive” or “user seductive.”
Even though it is challenging to implement an EIS
that meets executive information needs and is ex-
tremely easy to use, a number of EISs has
achieved these objectives (Applegate and
Osborn, 1988; Houdeshel and Watson, 1987).
An EIS Development
Framework
According to Sprague (1980), a development
framework is “helpful in organizing a complex
subject, identifying the relationships between the
parts, and revealing the areas in which further
developments will be required” (p.6). It guides
practitioners in developing systems and provides
insights for academicians in identifying where
research needs to be performed. Gorry and Scott
Morton’s (1971) framework for MIS and
Sprague’s (1980) for DSS are two of the best
known and most useful frameworks. Turban and
Schaeffer (1987) suggest the need for an EIS
development framework. This article provides
such a framework based on the EIS literature, our
experiences in developing EIS, and discussions
with vendors, consultants, and EIS staff
members.
The EIS development framework introduced here
is illustrated by the structural perspective
depicted in Figure 1. With this perspective, there
are key elements and interactions among the
elements that are important when developing an
EIS. The elements include executives, functional
area personnel (e.g., line managers, staff person-
nel, and data suppliers), information systems per-
sonnel, vendors, data, and information
technology. The interactions are in the form of
pressures, human interactions, and data flows.
The development of an EIS is a dynamic process
that places the key elements and interactions in
motion. In order for this to be successful, an ap-
propriate development process must be used.
This consideration is another important part of
the framework.
From the users’ perspective, the dialog with the
system is of fundamental importance. It includes
what must be known in order to use the system,
how to direct the system’s actions, and how the
output is presented by the system (Bennett,
MIS Quarterly/March 1991 15
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Figure 1. Structural Perspective of the EIS Development Framework
1977). The dialog is another important part of the
framework.
In summary, the EIS development framework in-
cludes a structural perspective, the development
process, and the user- system dialog. There are
a number of aspects associated with each. Those
that are explored in this research are identified
in Table 1.
The Study
The research study was begun in the spring of
1988 to investigate current EIS practices. The
authors mailed a multi-part questionnaire to a
large sample of geographically dispersed firms.
The first part of the questionnaire defined an
executive information system. The definition is
important because EISs are the most recent
16 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Table 1. Aspects of the EIS Development
Framework
STRUCTURAL
Personnel
EIS Initiator
Executive Sponsor
Operating Sponsor
EIS Builder/Support Staff
EIS Users
Functional Area Personnel
IS Personnel
Data
Internal
External
DEVELOPMENT PROCESS
External and Internal Pressures
Cost/Benefit Analysis
Costs
Development Costs
Annual Operating Costs
Development Time
Development Methodology
Hardware
Software
Spread
Evolution
Information Provided
EIS Capabilities
USER-SYSTEM DIALOG
Knowledge Base
Training
User Documentation
System User
Action Language
User-System Interface
System Response Time
Presentation Language
Multiple Information Formats
Color
computer-based information system to evolve,
and, therefore, a precise definition of EIS is not
universally accepted among academicians and
practitioners. The second part of the question-
naire gathered demographic data on each
organization. Finally, the questionnaire sought
data concerning the development, operation,
support, and capabilities of the EIS in the
organization. Suggested changes made after two
pretests were incorporated into the final survey
instrument.
The survey population was chosen from three
groups. The first group attended either the
DSS-87 or DSS-88 conferences. One hundred
and eighty-five questionnaires were sent to this
group. Questionnaires were not sent to attendees
from educational institutions or consulting firms.
The second group, all of whom received ques-
tionnaires, consisted of the 100 firms identified
by a Computerworld survey as having invested
the most effectively in information systems. The
authors believed that organizations that are
leaders in the use of information systems (IS) are
likely candidates to have an EIS. The third group
consisted of 19 firms known by the authors to
have an EIS but were not included into the first
two groups. Each firm was carefully checked to
ensure that the firm was not included in more
than one group. Because 18 firms appeared
more than once, a total of 286 questionnaires
were mailed. The survey was not a random sam-
ple. Because most firms had not developed an
EIS at this point in time, a frame was used that
maximized the likelihood of contacting firms with
an EIS.
Initially, the authors received 72 usable
responses, with 30 of the firms indicating that
they had an EIS, and 42 indicating that they did
not. Five weeks after the first mailing, another
questionnaire was mailed to non-respondents.
This follow-up resulted in responses from 20 ad-
ditional firms with an EIS and 20 with none. The
profile of responses from the second group cor-
responded closely with the profile of the initial
responses. A total of 112 usable responses was
received for a response rate of 39.1 percent. The
number of companies with an EIS was 50, which
provides the “n” on which percentages are
based when describing current practices in this
article. In some cases, the respondents did not
answer every question. In such instances, the
percentages calculated are based on the number
of responses received.
Findings and Discussion
Demographics
Organizations in this survey represent a variety
of industries located in widely dispersed
MIS Quarterly/March 1991 17
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
geographic areas (see Figure 2). Their total
corporate assets average $5.37 billion, with only
three firms reporting total assets of less than
$1 billion. Forty-eight respondents listed their
positions in their firms (see Figure 2). The largest
number of respondents are IS managers, fol-
lowed by executives and IS staff members. The
respondents averaged 18.74 years of work ex-
perience, 13.78 years of IS work experience, and
2.77 years of EIS experience.
Forty-seven firms (94 percent) had an operational
EIS, and three firms (6 percent) were far enough
along in developing one that they were able to
partially answer the questions on the survey. The
latter three firms all indicated that they would
have an operational EIS in less than one year.
While some EISs date back to the late 1970s
(Houdeshel and Watson, 1987), most of them are
recent. The survey findings support this state-
ment as 40 firms (80 percent) indicated that their
EISs were less than three years old. The average
age of an EIS in this survey is two years.
A structural perspective
Personnel
Thirty-four firms (68 percent) indicated that a
company executive(s) served as the initiator of
the development of the EIS. Survey respondents
were allowed to define the term “executive” in
the context of their own organizations. Informa-
tion systems personnel initiated EIS development
in 14 firms (28 percent). Finally, the information
center in one firm (2 percent) initiated EIS
development.
The finding that IS personnel initiated EIS
development in 14 firms is somewhat surprising
because the literature indicates that executives
initiate EIS development (Houdeshel and Wat-
son, 1987; Stecklow, 1989). However, 11 of these
14 firms (79 percent) had EISs that were less than
two years old. Of the 34 firms with EIS initiated
by executives, 19 (56 percent) had EISs that were
less than two years old. These numbers suggest
that executives motivated EIS development when
these systems first evolved. Few IS departments
had the confidence of management and/or the
risk-taking propensity to push for an EIS.
However, as the number of EIS success stories
has grown, more IS departments are taking the
lead in advocating EIS development by keeping
abreast of technological developments and com-
municating the potential benefits of the
technology to senior executives (Volonino and
Drinkard, 1989).
EIS development is spurred by a highly placed
senior executive who serves as the system’s ex-
ecutive sponsor (Barrow, 1990; Rockart and
DeLong, 1988). This person is typically the presi-
dent or a vice president of the company. Rockart
and DeLong (1988) suggest that three major
responsibilities of the executive sponsor include
making the initial request for the system; stay-
ing on top of the system’s development and pro-
viding direction and feedback about proposed
applications; and communicating strong and con-
tinuing interest to those with a stake in the
system, such as key staff groups and line
managers supplying data.
In this study, 42 firms (84 percent) reported hav-
ing executive sponsors for their EISs. Interesting-
ly, 62 percent of the executive sponsors hold
positions other than CEO or president (see Table
2). A partial explanation for this finding relates
to the scope of the EIS. While it is not explored
in this survey, the authors are familiar with a
number of EISs that serve a functional area rather
than the entire organization. In these situations,
it is logical that the executive sponsor would be
the vice president from the functional area
served.
The executive sponsor typically assigns an
operating sponsor to manage the day-to-day
development of the EIS (Rockart and DeLong,
1988). The operating sponsor is often a senior
executive who has an interest in having an EIS
for his or her own purposes. An information
systems project manager may serve as the
operating sponsor. The operating sponsor works
with executives, specialized staff, functional area
personnel, IS personnel, and vendors in creating
the EIS.
Forty-five firms (90 percent) reported having an
operating sponsor, and 42 firms listed the
operating sponsor’s position. The operating
sponsor held a variety of positions, the most
prevalent being the manager or director of IS (42
percent of firms) (see Table 3). This finding is dif-
ferent from what might be expected because the
literature suggests that the operating sponsor is
18 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Respondents by Geographical Area
Midwest 26%
Northeast 40%
Respondents by Industry
Manufacturing 28%
Financial 18%
Communications 14% ‘ :
Other 24%0
Health Care 8%
Utilities 8%
Respondents by Position in the Firm
……………!:i: IS Managers 38%
Executives 21% o
Other 12%
IS Staff Members 19%0 Functional Area
.. . . . . . . . . . . . . .. .. . . .. .. .. . . .. . . . . .. .
Staff Members 10%
Figure 2: Respondents by Location, Industry, and Position
MIS Quarterly/March 1991 19
Executive Information Systems
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
typically a senior executive (Rockart and DeLong,
1988).
The EIS builder/support staff is responsible for
creating and maintaining the EIS (Paller and
Laska, 1990; Rockart and DeLong, 1988). The
staff may be either newly created or an existing
organizational unit given a new charge. For ex-
ample, a unit that provides specialized informa-
tion and presentation materials to senior
management can be given EIS responsibilities
(Houdeshel and Watson, 1987). It is likely that
an existing group will require help with technical
matters. This lack of technical skills is not the
case when IS personnel are responsible for the
EIS, but IS personnel are often judged to be out
of sync with the needs of senior management or
too busy with other activities. Consultants and
vendors can also be involved, especially during
initial development.
All firms in this survey had EIS builder/support
teams, with 37 firms (74 percent) indicating that
their group consisted of five or fewer full-time peo-
ple. The average size of the team was four peo-
ple. Table 4 shows that the four categories of
personnel most commonly found on the EIS team
are end-user support personnel (58 percent of
firms), systems analysts (54 percent), program-
mers (44 percent), and executive staff support
personnel (40 percent). Only seven firms (14 per-
cent) reported using vendor personnel when
developing their EIS.
The builder/support team should include person-
nel with a mixture of business and technical skills
because the team must work closely with many
different people in the firm (e.g., executives, the
IS department, and functional area personnel)
(Reck and Hall, 1986; Rockart and DeLong,
1988). The business skills typically come from
people who have experience in the company. The
technical skills often come from IS personnel,
either by virtue of being assigned to the staff or
given specific responsibilities for supporting EIS
activities (see the dotted-line relationship in
Figure 1).
Respondents were asked to rank the top five
skills in order of importance. Five points were
awarded to the most important skill, four points
to the second most important skill, and so on. The
ability to work well with executives was found to
be the most necessary skill for a development
team member, followed by knowledge of the
business and interpersonal skills (see Table 5).
Technical skills ranked only fourth.
While it was not explored in the survey, it is worth
noting that the EIS builder/support group can
have a variety of organizational structures. One
approach is to have a centralized group that
reports to IS or a functional area. Another ap-
proach is to have a small, centralized group with
functional area personnel working on a part-time
basis performing tasks such as identifying infor-
mation requirements and supplying data. These
tasks are in addition to other job responsibilities.
This arrangement matches up well with the skills
that the support group needs in order to work ef-
fectively with executives.
The executive sponsor, operating sponsor, and
EIS staff identify the users of the EIS. This group
is usually small initially and expands over time.
A key to the success of the EIS is identifying the
system and information requirements of the ex-
ecutive users (Stecklow, 1989). A variety of
methods can be used, including participation in
strategic planning sessions, formal CSF ses-
sions, informal discussions, monitoring executive
activities, discussions with staff support person-
nel, software tracking of system usage, and
others (Watson and Frolick, 1988).
Functional area personnel are an important
source of data for the EIS, and an implementa-
tion strategy should be pursued that encourages
their cooperation and support for the system.
Before implementation of an EIS, much of the
needed data are already being gathered but often
only for the executives of the functional area in
which the data originate. Two of the major
organizational resistances to EIS are staff per-
sonnel who feel threatened by the possibility of
a diminished role in supplying information to ex-
ecutives and subordinate line managers who fear
that their operations will be too visible to top
management (Argyris, 1971; Carroll, 1988;
Rockart and DeLong, 1988).
Information systems personnel may not lead the
EIS project, but their support, cooperation, and
assistance are critical (Leibs, 1989). Helping
select and install hardware and software, pro-
viding maintenance, trouble-shooting problems,
and providing access to machine-resident data
are some of the support responsibilities that fall
to IS personnel. In organizations where IS per-
sonnel has the attention and confidence to top
20 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Table 2. Positions Held by Executive Sponsors
Position Percent of Firms
Chief Executive Officer 21
President 17
Chief Financial Officer 14
Vice President 42
Controller 6
Table 3. Positions Held by Operating Sponsors
Position Percent of Firms
Manager or Director of IS 50
Manager or Director of Functional Areas 14
Vice President 12
Analyst 10
Staff 7
Consultant 7
Table 4. EIS Development Team Members
Category Percent of Firms
End-user support personnel 58
Systems analysts 54
Programmers 44
Executive staff 40
Executive 22
Vendor personnel 14
Others 14
Table 5. Important Skills for the EIS Development Team
Skill Total Points
Ability to work well with executives 161
Knowledge of the business 143
Interpersonal skills 141
Technical skills 133
Ability to organize data 115
Other 12
management, they may be able to create an in-
terest in the creation of an EIS (Volonino and
Drinkard, 1989). This task is accomplished by
demonstrating what an EIS is and the kind of in-
formation it provides. Possible demonstration
strategies include showing a potential executive
sponsor an EIS in another company; arranging
a vendor-provided demonstration, ideally using
company data important to the executive; or pro-
totyping an EIS in-house.
MIS Quarterly/March 1991 21
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Data
Data play a critical role in an EIS because they
are the basis for the information provided
(Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). The data can come from inter-
nal or external sources and can be hard or soft.
The EIS can require that new data be collected
and stored. Much of the internal data is extracted
from existing organizational databases that are
used by transaction processing systems and
functional area applications. This tends to be
hard data. The use of this hard data in an EIS
is not as straightforward as it might seem,
however, because of different reporting and up-
dating cycles, functional area feelings of data
ownership, and multiple, incompatible databases
(e.g., inconsistent data definitions). Other inter-
nal data come from human sources and often are
soft in nature and are critical to understanding
complex problems (Mintzberg, 1975; Zmud,
1986). Included can be news, rumors, opinions,
ideas, predictions, explanations, and plans. Col-
lecting, analyzing, and entering these data to an
EIS tends to be very labor-intensive but adds con-
siderably to the richness of the information
provided.
Firms in the survey listed a variety of internal data
sources. The corporate database is a common
source of internal data for most (82 percent) of
the firms. Other internal data sources include the
functional areas of the firm (62 percent),
documents (38 percent), and humans (34 per-
cent). These data indicate the richness and varie-
ty of data sources that can be used by an EIS.
Further, the data illustrate the extensive data ac-
cess requirements associated with an EIS.
External data are also important to an EIS
(Runge, 1988). Like internal data, they can be
hard or soft and can come from existing
databases or require special collection efforts.
Data sources include external databases (e.g.,
Dow Jones News Retrieval), published data,
customers, and suppliers. External data sources
primarily noted in this survey include news ser-
vices (56 percent of firms), stock markets (46 per-
cent), and trade/industry data (34 percent).
The development process
The executive sponsor’s interest in the develop-
ment of an EIS can be the consequence of ex-
ternal and internal pressures (Gulden and Ewers,
1989; Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). The external pressures come
from the firm’s external environment and can in-
clude environmental turbulence (e.g., rapidly
changing costs of raw materials), increased com-
petition, and increased government regulations.
Internalpressures include the need for new, bet-
ter, or more timely information; having to manage
organizations that are increasingly complex and
difficult to run; and the need for more efficient
reporting systems.
The study asked respondents to rank order the
three most important external pressures and the
three most important internal pressures. Three
points were awarded to the most important
pressure in each category, two points to the
second most important pressure, and one point
to the third most important pressure.
The most critical external pressure is an increas-
ingly competitive environment. Other critical ex-
ternal pressures, in descending order, include the
rapidly changing external environment and the
need to be more proactive in dealing with the ex-
ternal environment (see Table 6).
The survey findings for internal pressures (see
Table 6) reveal that respondents consider the
need for timely information to be most critical.
Other internal pressures include the need for im-
proved communication, the need for access to
operational data, and the need for rapid status
updates. An interesting finding is that
respondents place the need for more accurate
information as the least critical internal pressure.
This seems to indicate that EIS users already
consider the information they receive to be ac-
curate.
Many researchers observe that cost/benefit
analyses are difficult to perform on EIS because
of the difficulty in quantifying many of the benefits
(Houdeshel and Watson, 1987; Moad, 1988;
Rockart and DeLong, 1988; Rockart and Treacy,
1982). These researchers suggest that there is
simply an intuitive feeling that the system will
justify its costs. After the system becomes opera-
tional, specific benefits and cost savings may
be identifiable (Wallis, 1989). Forty-four firms
answered this questionnaire item. Their
responses support these assertions; forty-two
respondents (95 percent) indicate that their firms
assessed potential benefits of their EIS through
intuitive feelings about improved decision mak-
22 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Table 6. Pressures Leading to EIS Development
External Pressures Total Points
Increasingly competitive environment 113
Rapidly changing external environment 59
Need to be more proactive in dealing
with external environment 46
Need to access external databases 25
Increasing government regulations 15
Other 8
Internal Pressures
Need for timely information 61
Need for improved communication 39
Need for access to operational data 35
Need for rapid status updates on
different business units 34
Need for increased effectiveness 27
Need to be able to identify historical
trends 27
Need for increased efficiency 25
Need for access to corporate database 25
Other 17
Need for more accurate information 15
ing. Only two firms (5 percent) assessed hard
dollar benefits.
Costs
Even though most firms do not measure hard
dollar benefits, many firms do consider the costs
involved before undertaking EIS development.
Most firms estimate software costs (79 percent),
hardware costs (68 percent), and personnel costs
(68 percent). Fewer firms (32 percent) estimate
training costs, perhaps because training costs
are anticipated to be minimal.
In conjunction with data on firms that estimated
EIS costs before development, this study
gathered data on actual EIS development costs
and operational costs. Development costs are
those costs incurred creating the first version of
the EIS. Thirty-three firms provided development
costs for their EIS. The firms averaged $128,000
on software, $129,000 on hardware, $90,000 on
personnel, and $18,000 on training. These firms
also supplied annual EIS operating costs, which
were found to average $117,000 on personnel,
$46,000 on software, $29,000 on hardware, and
$16,000 on training. These numbers suggest that
an EIS is expensive and, consequently, may be
limited to larger firms with considerable financial
resources.
Of note is that annual operating costs for person-
nel appear to be higher than personnel develop-
ment costs. A possible explanation for this finding
is that companies may need additional people to
handle increases in the number of users,
screens, and system capabilities.
The time to develop the initial version of an EIS
is important. As with other systems that support
decision making, the first version of an EIS
should be developed quickly and presented to
users for their reactions (Moad, 1988; Runge,
1989). Forty-six firms (92 percent) developed their
EIS using an iterative, prototyping methodology
and four firms (8 percent) used a formal systems
development life cycle approach.
The hardware and especially the software used
in developing the first version may or may not be
what are used in later versions. At one extreme,
MIS Quarterly/March 1991 23
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
a few screens can be designed using existing
software to run on workstations already in place
(Rinaldi and Jastrzembski, 1986). Information for
the screens can be entered manually. This ap-
proach minimizes development time and cost. At
the other extreme, a commercial EIS package
can be purchased and installed. The EIS builders
use the package to create the initial screens and
to supply them with information. This approach
minimizes the difficulties of moving to later ver-
sions if the EIS proves to be successful.
There are several hardware configurations possi-
ble with an EIS (Paller and Laska, 1990; Rockart
and DeLong, 1988). Forty-eight companies in-
dicated the hardware configuration used for their
EIS. Forty firms (83 percent) use a mainframe ap-
proach. The mainframe approach includes 18
firms (37 percent) that employ a shared main-
frame, 17 firms (35 percent) that use a PC net-
work connected to a mainframe, and five firms
(11 percent) that employ a dedicated mainframe.
Eight firms (17 percent) use a PC network with
a file server for their hardware configuration.
More vendors have been offering local area
network-based EIS products (e.g., Lightship from
Pilot) since this study was conducted.
The availability of commercial software has con-
tributed considerably to the growth of EIS. Prod-
ucts from vendors such as Comshare
(Commander EIS), Pilot (Command Center), IBM
(Executive Decisions), and EXECUCOM (Ex-
ecutive Edge) facilitate the development and
maintenance of an EIS. These products support
ease of use (e.g., mouse or touch screen opera-
tion), access to data, screen design and
maintenance, interfaces to other software (e.g.,
Lotus 1-2-3), and other system requirements.
An EIS can be developed using in-house
developed software, vendor-supplied software, or
some combination of the two (Paller and Laska,
1990; Rockart and DeLong, 1988). Twelve firms
(24 percent) developed their EIS using custom-
built, in-house software; 12 firms (24 percent)
used vendor-supplied software; and 26 firms (52
percent) used a combination of in-house and ven-
dor software. Of the 38 firms that employ at least
some vendor-supplied software, nine firms (24
percent) use Pilot’s Command Center, seven
firms (18 percent) use Comshare’s Commander
EIS, five firms (12 percent) use Interactive Im-
age’s EASEL, and the remaining 17 firms (46 per-
cent) use a wide variety of other vendor software.
These results are not surprising; Pilot and Com-
share are generally recognized to be the two
leading vendors of EIS software.
Over time an EIS evolves in terms of the number
of users, the number of screens, the content and
format of the screens, and EIS capabilities
(Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). In some cases the EIS may be
“pushed” on users, but a more desirable ap-
proach is to allow “demand pull” to occur. The
latter normally occurs as subordinates learn that
their superiors have access to certain informa-
tion and they “want to see what their bosses are
looking at.” Still, some executives may
legitimately have little interest in using the EIS
because it contains little information relevant to
them, or they have well-established alternative
sources of information.
Executive information systems usually spread
over time. Spread refers to the increase in the
number of users who have access to the EIS
(Rockart and DeLong, 1988). It can be argued
that an EIS that does not spread is likely to fail
(Friend, 1990). The survey question about spread
referred only to the number of users over time
and did not specify that the users be executives.
Therefore, the users could include executives,
executive staff, and other organizational person-
nel. This study found that the EIS supported an
average of 7.75 users initially, with a steadily in-
creasing number of users over time, as can be
seen in Figure 3. The “n”s shown in Figure 3 are
the number of respondents who provided data
for the various points in time.
Evolution refers to additional capabilities and in-
formation provided by an EIS over time (Rockart
and DeLong, 1988). This study gathered data on
the number of screens available to users over
time. An average of 55.8 screens were available
initially, and the number of available screens in-
creased in each time period (see Figure 3). This
increase implies that users usually want more in-
formation as time passes and they become
familiar with the system.
Even though the data show that the number of
screens consistently increases, outdated screens
must be deleted and other screens modified. Ad-
ding, modifying, and deleting screens is an im-
portant responsibility of the EIS support staff.
Software tracking of system use is very helpful
in identifying screens that may need to be
changed. Screen content and format can change
24 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

n=4
n–8
=12
n=23
l-n34
n=31
I I I I
6mrnos 1 yr
I I I Iyr
2 yrs
I I 1
3 yrs
CurrI
Curren.y
Time After Initial Introduction
700
600
6 mos 1 yr 2 yrm 3 yrs Currently
Time After Initial Introduction
Figure 3. EIS Spread
MIS Quarterly/March 1991 25
Executive Information Systems
L
o D 0
.t
:2 z
0
CD
200
190 –
180 –
170 –
160 –
150 –
140 –
130 –
120 –
110 –
100 –
90 –
80 –
70 –
60 –
50 –
40 –
30 –
20 –
10 -.
0
n=–37
c
C L
0
E
:3
z
0
c)
500
400
300
200
100 –
0
n=33
r
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
over time. As an example of this change, screens
may become denser in content as users become
more familiar with them (Houdeshel and Watson,
1987). Information that was spread over several
screens may be placed on a single screen, which
can result in format changes.
To be most effective in supporting executives, an
EIS must provide information from many areas
(Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). It can supply information about
the industry in which the firm competes, company
information, work unit information, and informa-
tion that may be of interest to only a single ex-
ecutive. The information can span subsidiaries,
divisions, functional areas, and departments.
The surveyed firms reported that their EISs pro-
vided information by strategic business unit (88
percent), functional area (86 percent), key per-
formance indicator (71 percent), product (67 per-
cent), and location (53 percent). These
percentages demonstrate that EISs are able to
supply information for various perspectives, thus
allowing users flexibility in the information they
can access.
An EIS can have a variety of capabilities (Friend,
1986; Kogan, 1986). Eighty-eight percent of the
firms in this study state that their EIS provides
access to current status information about the
company. Other capabilities provided in a majori-
ty of firms are electronic mail, external news ac-
cess, and access to other external databases
(see Table 7).
Executives may want access to the EIS while at
home (Wallis, 1989). Executives who are travel-
ing may also want to access the EIS. This off-
site use creates special communications, securi-
ty, and support responsibilities. This is just one
example of a system requirement that can evolve
over time.
The dialog
From the executive’s perspective, the dialog with
the EIS is the most important component of the
system (Zmud, 1986). As was pointed out
previously, because of the nature of executives
and executive work, the system should be quite
user-friendly. It should avoid elaborate logon pro-
cedures. Movement among EIS components
should be seamless (e.g., e-mail might be a main
menu option and not require a separate user ID).
The system should provide context-dependent
online help. Menus and a keyword index for
locating screens should be included to help the
executive find information. Sequence or com-
mand files should be created that allow ex-
ecutives to page through regularly viewed
screens. The inclusion of a “drill-down” capability
allows executives to go into more detail when an
exceptional situation is encountered. The screens
can provide the names’ and telephone numbers’
of people who can discuss the information
presented.
Training on the use of the EIS should be one-on-
one. Any system that requires more than a few
minutes of training probably does not satisfy
ease-of-use requirements (Carroll, 1988). User
documentation should not be necessary for a
well-designed EIS. If documentation is provided,
it should be kept to a single page.
The system user of the EIS may be the executive,
or it may be operated by an intermediary (Rockart
and DeLong, 1988). Forty-eight respondents
answered this item on the questionnaire. Forty-
Table 7. Capabilities Available on the EIS
Capability Percent of Firms
Access to current status 88
Electronic mail 65
Other external database 57
External news access 56
Word processing 34
Spreadsheet 37
Automated filing 22
Other 14
26 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
three firms (89 percent) report that their ex-
ecutives use the EIS directly, and five firms (11
percent) report that intermediaries operate the
system.
In keeping with the fact that an EIS must be
highly user-friendly, the user interface and
response time of the EIS are critical (Houdeshel
and Watson, 1987; Rockart and DeLong, 1988).
Ninety-two percent of the EISs employ a
keyboard interface, one-half a mouse, and one-
fourth a touch screen. These percentages in-
dicate that there are multiple interfaces available
on many of the EISs in this sample. The mean
response time of the EISs in this survey was 2.8
seconds, with 42 firms (84 percent) reporting
average response times of less than five
seconds.
The EIS can provide a variety of capabilities for
selecting screens, Keystrokes can be employed
to move through menus or to identify particular
screens. Even though some executives are
adverse to using keyboards, this typically is not
a major problem if the required skills are not too
great. A keyboardless system can be provided
by using a mouse or a touch screen. Most
vendor-supplied software offer these methods of
system operation as options. Icons are commonly
used to make the system more intuitive.
Screens should include graphical, tabular, and
textual presentation of information. Most supplied
software provides a large variety of screen design
capabilities. Standards should be established for
any terms used, color codes, and graphic designs
(Smith and Mosier, 1984; Tullis, 1981). These
standards help to avoid misunderstandings and
reduce the amount of mental processing required
to interpret information.
Executive information systems should be able to
present information to the user in multiple formats
(e.g., graphical, tabular, and textual) (Friend,
1988; Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). Ninety percent of the EISs in this
study have graphical formats available, 90 per-
cent use textual formats, and 88 percent employ
tabular formats. These percentages suggest that
many EISs present information in multiple
formats.
Executive information systems make extensive
use of color in presenting information (Friend,
1988; Houdeshel and Watson, 1987; Rockart and
DeLong, 1988). Out of 47 respondents who
answered this question, 39 EISs (83 percent) in
this study employ color displays and eight (17
percent) do not.
Conclusion
This study has presented a framework for the
development of executive information systems
and data related to this framework from 50
organizations. In most cases, the data support
the “conventional wisdom” found in the
literature:
* EISs are a recent development.
* EIS development is typically driven by a senior
executive.
* An EIS has an executive sponsor, and this per-
son is normally a CEO or a vice president.
* The development of an EIS is approved with
little formal cost/benefit analysis.
* EIS development groups include a variety of
personnel with a mixture of business and
technical skills.
* An EIS obtains data from multiple internal and
external sources.
* An EIS provides broadly based information.
* Pilot’s Command Center and Comshare’s
Commander EIS are the two most popular ven-
dor products for creating an EIS.
* The initial version of an EIS is developed
quickly.
* Most EISs are mainframe-based.
* An EIS is created using an iterative, prototyp-
ing development methodology.
* The number of users and the number of
screens of an EIS increase over time.
* Nearly all EISs are used directly by executives
without intermediaries.
* An EIS presents information in graphical, tex-
tual, and tabular formats.
* Most EISs use color in presenting information.
The study also provides insights about areas
where little is previously reported:
* The increasingly competitive environment and
the need for timely information are the main ex-
MIS Quarterly/March 1991 27
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
ternal and internal pressures that lead to the
development of an EIS.
* On average, the total costs of developing an
EIS are $365,000, and the annual costs to
maintain one are $208,000. It should be noted
that the firms in this study are large, and
smaller companies might develop more limited,
and therefore less expensive, EIS due to cost
considerations.
* The average size of an EIS development group
is four people.
* On average, about one-fourth of the EISs are
created using in-house developed software,
one-half with vendor supplied plus in-house
software, and one-fourth with only vendor-
supplied software.
* On average, it takes 4.9 months to develop the
initial version of an EIS.
* On average, 92 percent of all EISs employ a
keyboard interface, one-half a mouse, and one-
fourth a touch screen.
And finally, there were a few surprising findings:
* In some firms, EIS development is initiated by
IS, and this seems to be a growing trend.
* A vice president is most often the executive
sponsor for an EIS.
* An IS manager or director is most often the
operating sponsor for an EIS.
While this and other studies provide information
about EIS, there is much that still needs to be
learned. After reading the MIS literature, one is
surprised by how little academic research has
been conducted on EIS. Most of the literature on-
ly provides glowing descriptions of specific EISs
and how they are being used. In conducting this
research, a variety of interesting and important
EIS research questions surfaced.
* Is the organizational position and level of com-
mitment of the executive sponsor related to EIS
success?
* What considerations are most important when
selecting an operating sponsor?
* How can the benefits of an EIS be assessed
in advance?
* How does the software used in building an EIS
affect the development process and system
success?
* What level of staffing and organization struc-
ture are best for the EIS builder/support staff?
* What methods can be most effectively used to
identify executives’ information requirements?
* What are the major EIS data management pro-
blems and their solutions?
* What impact does the inclusion of soft data
have on EIS success?
* What are the major problems associated with
EIS “spread” and its evolution?
* How can EIS functionality be increased while
maintaining ease-of-use?
* What emerging technologies (e.g., voice, op-
tical disc) can be effectively used with EIS?
* What are the most effective screen presenta-
tion formats for an EIS?
Currently, the technology for EIS is evolving
rapidly, and future systems are likely to be dif-
ferent from those that are in use today. A number
of interesting and promising changes that can be
anticipated include:
* Better integration with other applications. For
example, better support can be provided by in-
tegrating EIS with decision support systems,
group decision support systems, and expert
systems. A DSS can provide analysis
capabilities when problems are identified us-
ing an EIS; an EIS can be used to provide in-
formation in a decision room setting; and an
expert system can be created to help guide ex-
ecutives in using the EIS effectively.
* Better commercial EIS software. Some of the
advances to expect include better interfaces to
organizational data and other organizational
systems, enhanced capabilities for monitoring
system usage, industry-specific template
screens, and expanded sets of builders’ tools
(e.g., icons for use in screen development).
* Better executive-system interfaces. While
keyboards are required for e-mail and most
decision support applications, mouse and
touchscreens are attractive alternatives for
other types of system use. Animation is likely
to be increasingly used to “add life” to infor-
mation. Television may be available in a win-
dow. Voice may be used to direct the system.
An EIS is a high-risk system, and many failures
have occurred (Watson and Glover, 1989). By
28 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
following the EIS development framework,
however, the likelihood of having a failure should
be reduced. Over time, as more experience is
gained, better products emerge, and more
research findings are available, the chances for
having an EIS success should grow.
References
Albala, M.. “Getting to the Pulse of the
Company,” Personal Computing (12:10),
October 1988, pp. 196-198.
Alexander, M. “Executive Information Systems
Catch On,” Computerworld, February 27,
1989, p. 31.
Applegate, L.M. and Osborn, C.S. “Phillips 66
Company: Executive Information Systems,”
Harvard Case (9-189-006), Harvard Business
School, Boston, MA, December 1988.
Argyris, C. “Management Information Systems:
The Challenge to Rationality and Emotion-
ality,” Management Science (17:6), June
1971, pp. B275-292.
Barrow, C. “Implementing an Executive Informa-
tion System: Seven Steps for Success,”
Journal of Information Systems Management
(7:2), Spring 1990, pp. 41-46.
Bennett, J. “User-Oriented Graphics Systems for
Decision Support in Unstructured Tasks,” in
User-Oriented Design of Interactive Graphics
Systems,” S. Treu (ed.), Association for Com-
puting Machinery, New York, NY, 1977.
Burkan, W.C. “Making EIS Work,” DSS 88 Tran-
sactions, The Institute of Management
Sciences, Providence, RI, 1988, pp. 121- 136.
Carroll, P.B. “Computerphobe Managers,” The
Wall Street Journal, June 20, 1988. p. 21.
Computerworld. “The Premier 100,” Special
Supplement,.September 12, 1988, p. 9.
Friend, D. “Executive Information Systems:
Successes, Failures, Insights, and Miscon-
ceptions,” DSS 86 Transactions, The Institute
of Management Sciences, Providence, RI,
1986, pp. 35- 40.
Friend, D. “EIS and the Collapse of the Infor-
mation Pyramid,” Information Center (6:3),
March 1990, pp. 22-28.
Gorry, G.A. and Scott Morton, M.S. “A
Framework for Management Information
Systems,” Sloan Management Review (13:1),
Fall 1971, pp. 51-70.
Gulden, G.K. and Ewers, D.E. “Is Your ESS
Meeting the Need?” Computerworld, July 10,
1989, pp. 85-91.
Houdeshel, G. and Watson, H.J. “The Manage-
ment Information and Decision Support
(MIDS) System at Lockheed-Georgia,” MIS
Quarterly (11:1), March 1987, pp. 127-140.
Isenberg, D.J. “How Senior Managers Think,”
Harvard Business Review (62:6), November-
December 1984, pp. 81-90.
Kogan, J. “Information for Motivation: A Key to
Executive Information Systems That Translate
Strategy into Results for Management,” DSS
86 Transactions, The Institute of Management
Sciences, Providence, RI, 1986, pp. 6-13.
Kotter, J.P. “What Effective General Managers
Really Do,” Harvard Business Review (60:6),
November-December 1982, pp. 156-157.
Leibs, S. “EIS: It’s All Down Hill From Here,”
Information Week, May 1989, pp. 44-46.
Main, J. “At Last, Software CEOs Can Use,”
Fortune (119:6), March 13, 1989, pp. 77-83.
Mintzberg, H. “The Manager’s Job: Folklore and
Fact,” Harvard Business Review (53:4), July-
August 1975, pp 49-61.
Moad, J. “The Latest Challenge for IS Is in the
Executive Suite,” Datamation, May 15,1988,
p. 43.
Paller, A. and Laska, R. The EIS Book, Dow
Jones-lrwin, Homewood, IL, 1990.
Reck, R.H. and Hall, J.R. “Executive Information
Systems: An Overview of Development,”
Journal of Information Systems Management
(3:4), Fall 1986, pp. 25-30.
Rinaldi, D. and Jastrzembski, T. “Executive
Information Systems: Put Strategic Data at
Your CEO’s Fingertips,” Computerworld,
October 27, 1986, pp. 37-50.
Rockart, J.F. and Treacy, M.E. “The CEO Goes
On-Line,” Harvard Business Review (60:1),
January-February 1982, pp. 84-88.
Rockart, J.F. and DeLong, D.W. Executive
Support Systems: The Emergence of Top
Management Computer Use, Dow Jones-
Irwin, Homewood, IL, 1988.
Runge, L. “On the Executive’s Desk,” Informa-
tion Center (4:6), June 1988, pp. 34-38.
Smith, S.L. and Mosier, J.N. “Design Guidelines
for User- System Interface,” Software Report
(ESD-TR-84-190), The MITRE Corporation,
Bedford, MA, September 1984.
Sprague, R.H. “A Framework for the Develop-
ment of Decision Support Systems,” MIS
Quarterly (4:4), December 1980, pp. 1-26.
MIS Quarterly/March 1991 29
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Executive Information Systems
Stecklow, S. “The New Executive Information
Systems,” Lotus, April 1989, pp. 51-55.
Tullis, T.S. “An Evaluation of Alphanumeric,
Graphic, and Color Information Displays,”
Human Factors (23:5), October 1981, pp.
541-550.
Turban, E. and Schaeffer, D.M. “A Comparative
Study of Executive Information Systems,”
DSS 87 Transactions, The Institute of
Management Sciences, Providence, RI, 1987,
pp. 139-148.
Turban, E. and Watson, H.J. “Integrating Expert
Systems, Executive Information Systems, and
Decision Support Systems,” DSS 89 Trans-
actions, The Institute of Management
Sciences, Providence, RI, 1989, pp. 74-82.
Volonino, L. and Drinkard, G. “Integrating EIS
into the Strategic Plan: A Case Study of
Fisher-Price,” DSS 89 Transactions, The
Institute of Management Sciences, Providence,
RI, 1989, pp. 37-45.
Wallis, L. “Power Computing at the Top,” Across
the Board (26:1-2), January-February 1989,
pp. 42-51.
Watson, H.J. and Frolick, M. “Determining Infor-
mation Requirements for an Executive Infor-
mation System,” unpublished working paper,
Department of Management, University of
Georgia, Athens, GA, 1988.
Watson, H. and Glover, H. “Common and
Avoidable Causes of EIS Failure,” Computer-
world, December 4, 1989, pp. 90-91.
Zmud, R.W. “Supporting Senior Executives
Through Decision Support Technologies: A
Review and Directions for Future Research,”
in Decisions Support Systems: A Decade in
Perspective, E.R. McLean and H.G. Sol (eds.),
Elsevier Science Publishers B.V., North-
Holland, Amsterdam, 1986, pp. 87-101.
About the Authors
Hugh J. Watson holds the C. Herman and Mary
Virginia Terry Chair of Business Administration
and is the director of MIS programs at the Univer-
sity of Georgia. He is the author of 15 books and
over 60 articles in journals such as MIS Quarterly,
Communications of the ACM, Journal of Manage-
ment Information Systems and Management
Science. He directs the EIS program of research
at the University of Georgia.
R. Kelly Rainer, Jr. is assistant professor in the
Department of Management at Auburn Univer-
sity, Auburn, Alabama. He is the author of articles
in several journals, including the Journal of
Management Information Systems, Journal of In-
formation Systems Management, Journal of
Systems Management, and Decision Support
Systems. His current research involves executive
information systems.
Chang E. Koh is assistant professor in the
Department of Information Systems and Opera-
tions Management at the University of North
Carolina at Greensboro. He received his B.A. in
economics from Yonsei University, Seoul, South
Korea, and an M.B.A. from Bowling Green State
University. He is currently a doctoral candidate
in MIS at the University of Georgia. His current
research interests include executive information
systems, end-user computing, and data
management.
30 MIS Quarterly/March 1991
This content downloaded from 192.155.87.248 on Tue, 1 Oct 2013 21:45:43 PM
All use subject to JSTOR Terms and Conditions

http://www.jstor.org/page/info/about/policies/terms.jsp

Article Contents
p. 13
p. 14
p. 15
p. 16
p. 17
p. 18
p. 19
p. 20
p. 21
p. 22
p. 23
p. 24
p. 25
p. 26
p. 27
p. 28
p. 29
p. 30
Issue Table of Contents
MIS Quarterly, Vol. 15, No. 1 (Mar., 1991), pp. i-iv+1-144
Volume Information
Front Matter [pp. i – i]
Editor’s Comments: Re-Engineering the Organization [pp. iii – iv]
Issues and Opinions
On End-User Computing Satisfaction [pp. 1 – 4]
The Measurement of End-User Computing Satisfaction: Theoretical and Methodological Issues [pp. 5 – 10]
Executive Overview [p. 12]
Application
Executive Information Systems: A Framework for Development and a Survey of Current Practices [pp. 13 – 30]
Executive Overview [p. 32]
Application
Applications of Global Information Technology: Key Issues for Management [pp. 33 – 49]
Executive Overview [p. 50]
Application
Executive Information Requirements: Getting It Right [pp. 51 – 65]
Executive Overview [p. 66]
Application
On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices [pp. 67 – 86]
Executive Overview [p. 88]
Application
Identification of Strategic Information Systems Opportunities: Applying and Comparing Two Methodologies [pp. 89 – 103]
Executive Overview [p. 104]
Theory and Research
Decisional Guidance for Computer-Based Decision Support [pp. 105 – 122]
Executive Overview [p. 124]
Theory and Research
Personal Computing: Toward a Conceptual Model of Utilization [pp. 125 – 143]

project work/Executive Information Systems Their Impact on Executive Decision Making

project work/Management misinformation systems

By PROFESSOR RUSSELL L. A C K O F F ,
Director, Management Science Center,
University of Pennsylvania.
Management
T H E growing pre-occupation of operations
researchers and management scientists with
Management Information Systems (MISs) is apparent. In
fact, for some the design of such systems has almost
become synonymous with operations research or
management science. Enthusiasm for such systems is
understandable: it involves the researcher in a
romantic relationship with the most glamorous
instrument of our time, the computer. Such
enthusiasm is understandable but, nevertheless, some
of the excesses to which it has led are not excusable.
Contrary to the impression produced by the
growing literature, few computerized management
information systems have been put into operation. Of
those I have seen that have been implemented, most
have not matched expectations and some have been
outright failures. I believe that these near- and far-
misses could have been avoided if certain false (and
usually implicit) assumptions on which many such
systems have been erected had not been made. There
seem to be five common and erroneous assumptions
underlying the design of most MISs.
Give them more
Most MISs are designed on the assumption that the
critical deficiency under which most managers operate
is lack of relevant information. I do not deny that
most managers lack a good deal of information that
they should have, but I do deny that this is the most
important informational deficiency from which they
suffer. It seems to me that they suffer more from an
over abundance of irrelevant information.
This is not a play on words. The consequences of
changing the emphasis of an MIS from supplying
relevant information to eliminating irrelevant informa-
tion is considerable. If one is pre-occupied with
supplying relevant information, attention is almost
exclusively given to generating, storing, and retrieving
information: hence emphasis is placed on constructing
data banks, coding, indexing, updating files, access
languages and so on. The ideal which has emerged
from this orientation is an infinite pool of data into
which a manager can reach to pull out any information
he wants. If, on the other hand, one sees the
manager’s information problem primarily, but not
exclusively, as one that arises out of an over-
abundance of irrelevant information, most of which
was not asked for, then the two most important
functions of an information system become filtration
(or evaluation) and condensation. T h e literature on
MISs seldom refers to these functions let alone
considers how to carry them out.
My experience indicates that most managers receive
much more data (if not information) than they can
possibly absorb even if they spend all their time trying
to do so. Hence they already suffer from an informa-
tion overload. They must spend a great deal of time
separating the relevant from the irrelevant and
searching for the kernels in the relevant documents.
F o r example, I have found that I receive an average
of 43 hours of unsolicited reading material each week.
The solicited material is usually half again this
amount.
I have seen a daily stock status report that consists
of approximately 600 pages of computer print-out.
The report is circulated daily across managers’ desks.
I have also seen requests for major capital expenditures
that come in book size, several of which are distributed
to managers each week. It is not uncommon for many
managers to receive an average of one journal a day
or more. One could go on and on.
Unless the information overload to which managers
are subjected is reduced, any additional information
which a n MIS makes available cannot be expected to be
used effectively.
Even relevant documents have too much redun-
dancy. Most documents can be considerably
condensed without loss of content. My point here is
best made, perhaps, by describing briefly an experiment
that a few of m y colleagues and I conducted on the
OR literature several years ago. By using a panel of
well-known experts we identified four OR articles that
all members of the panel considered to be “above
average”, and four articles that were considered to be
“below average”. We asked the authors of the eight
articles to prepare “objective” examinations (duration
30 minutes) plus answers for graduate students who
were to be assigned the articles for reading. (The
Following our policy of reprinting important
papers selected from the mass of US management
literature we reproduce this article by Professor
Ackoff which first appeared in the December 1967
issue of “Management Science”.
4 MANAGEMENT DECISION

“Most management information systems are designed on the assumption
that the critical deficiency under which most managers operate is lack
of relevant information. I do not deny that most managers lack a good
deal of information that they should have, but I do deny that this is the
most important informational deficiency from which they suffer. It seems
to me that they suffer more from an over abundance of irrelevant
information.”
misinformation systems
authors were not informed about the experiment.)
Then we asked several experienced writers to reduce
each article to ⅔ and ⅓ of its original length only by
eliminating words. They also prepared a brief abstract
of each article. Those who did the condensing did
not see the examinations to be given to the students.
We then selected a group of graduate students who
had not previously read the articles and gave each one
four articles randomly selected, each of which was in
one of its four versions: 100 per cent, 67 per cent,
33 per cent, or abstract. Each version of each article
was read by two students. We gave all the students
the same examinations, compared their average scores
on the examinations.
F o r the above-average articles there was no
significant difference between average test scores for
the 100 per cent, 67 per cent, and 33 per cent versions,
but there was a significant decrease in average test
scores for those who had read only the abstract. For
the below-average articles there was no difference in
average test scores among those who had read the
100 per cent, 67 per cent, and 33 per cent versions,
but there was a significant increase in average test
scores of those who had read only the abstract.
T h e sample used was obviously too small for general
conclusions but the results strongly indicate the extent
to which even good writing can be condensed without
loss of information. I refrain from drawing the
obvious conclusion about bad writing!
It seems clear that condensation as well as filtration,
performed mechanically or otherwsie, should form an
essential part of an MIS, and that such a system should
be capable of handling much, if not all, of the
unsolicited as well as solicited information that a
manager receives.
Does the manager need the information
that he wants?
Most MIS designers “determine” what information
is needed by asking managers what information they
would like to have. This is based on the assumption
that managers know what information they need and
want it.
F o r a manager to know what information he needs
he must be aware of each type of decision he should
make (as well as does) and he must have an adequate
model of each. These conditions are seldom satisfied.
Most managers have some conception of at least some
of the types of decisions they must make. However,
their conceptions are likely to be deficient in a very
critical way, a way that follows from an important
principle of scientific economy: the less we understand
a phenomenon, the more variables we require to
explain it. Hence, the manager who does not under-
stand the phenomenon he controls, plays it “safe” and,
with respect to information, wants “everything”. The
MIS designer, who has even less understanding of the
relevant phenomenon than the manager, tries to
provide even more than everything. H e thereby
increases what is already an overload of irrelevant
information.
For example, market researchers in a major oil
company once asked their marketing managers what
variables they thought were relevant in estimating the
sales volume of future service stations. Almost seventy
variables were identified. The market researchers then
added about half again this many variables and
performed a large multiple linear regression analysis
of sales of existing stations against these variables and
found about 35 of them to be statistically significant.
A forecasting equation was based on this analysis. An
OR team subsequently constructed a model based on
only one of these variables, traffic flow, which
predicted sales better than the 35 variable regression
equation. T h e team went on to explain sales at
service stations in terms of the customers’ perception
of the amount of time lost by stopping for service. The
relevance of all but a few of the variables used by
the market researchers could be explained by their
effect on such perception.
The moral is simple: one cannot specify what
information is required for decision making until an
explanatory model of the decision process and the
system involved has been constructed and tested.
Information systems are sub-systems of control
systems. They cannot be designed adequately without
taking control in account. Furthermore, whatever else
regression analyses can yield, they cannot yield under-
standing and ‘ explanation of phenomena. They
describe and, at best, predict.
Improving a manager’s decision making
It is frequently assumed that if a manager is provided
with the information he needs, he will then have no
problem in using it effectively. The history of OR
stands to the contrary. F o r example, give most
SPRING 1968 5

managers an initial tableau of a typical “real” mathe-
matical programming, sequencing, or network problem
and see how close they come to an optimal solution.
If their experience and judgement have any value they
m a y not do badly, but they will seldom do very well.
In most management problems there are too many
possibilities to expect experience, judgement, or
intuition to provide good guesses, even with perfect
information.
Furthermore, when several probabilities are involved
in a problem the unguided mind of even a manager
has difficulty in aggregating them in a valid way. We
all know many simple problems in probability in which
untutored intuition usually does very badly (e.g., What
are the correct odds that 2 of 25 people selected at
random will have their birthdays on the same day of
the year?). For example, very few of the results
obtained by queuing theory, when arrivals and service
are probabilistic, are obvious to managers; nor are the
results of risk analysis where the managers use their
own subjective estimates of probabilities.
The moral: it is necessary to determine how well
managers can use needed information. When, because
of the complexity of the decision process, they cannot
use it well, they should be provided with either
decision rules or performance feed-back, so that they
can identify and learn from their mistakes.
More communication means better performance
One characteristic of most MISs, which I have seen,
is that they provide managers with better current
information about what other managers and their
departments and divisions are doing. Underlying this
provision is the belief that better inter-departmental
communication enables managers to co-ordinate their
decisions more effectively and hence improves the
organization’s overall performance. Not only is this
not necessarily so, but it seldom is so. One would
hardly expect two competing companies to become
more co-operative because the information each
acquires about the other is improved. This analogy
is not as far fetched as one might first suppose. F o r
example, consider the following very much simplified
version of a situation I once ran into. The simplifica-
tion of the case does not affect any of its essential
characteristics.
A department store has two “line” operations:
buying and selling. Each function is performed by a
separate department. The purchasing department
primarily controls one variable: how much of
each item is bought. The merchandising department
controls the price at which it is sold. Typically, the
measure of performance applied to the purchasing
department was the turnover rate of inventory. The
measure applied to the merchandising department was
gross sales; this department sought to maximize the
number of items sold times their price.
Now by examining a single item let us consider
what happens in this system. T h e merchandising
manager, using his knowledge of competition and
consumption, set a price which he judged would
maximize gross sales. In doing so he utilized price-
demand curves for each type of item. F o r each price
the curves show the expected sales and values on an
upper and lower confidence band as well (see Figure 1).
When instructing the purchasing department how
many items to make available, the merchandising
manager quite naturally used the value on the upper
confidence curve. This minimized the chances of his
running short which, if it occurred, would hurt his
performance. It also maximized the chances of being
over-stocked, but this was not his concern, only the
purchasing manager’s. Say, therefore, that the
merchandising manager initially selected price P1 and
requested that amount Q1 be made available by the
purchasing department.
In this company the purchasing manager also had
access to the price-demand curves. H e knew the
merchandising manager always ordered optimistically.
Therefore, using the same curve he read over from Q1
to the upper limit and down to the expected value from
which he obtained Q2, the quantity he actually intended
to make available. He did not intend to pay for the
merchandising manager’s optimism. If merchandising
ran out of stock, it was not his worry. Now the
merchandising manager was informed about what the
purchasing manager had done so he adjusted his price
to P2. The purchasing manager in turn was told that the
merchandising manager had made this readjustment so
he planned to make only Q2 available. If this process—
made possible only by perfect communication between
departments—had been allowed to continue, nothing
would have been bought and nothing would have been
sold. This outcome was avoided by prohibiting
communication between the two departments and
forcing each to guess what the other was doing.
Obviously I have caricatured the situation in order
to make the point clear: when organizational units
have inappropriate measures of performance which
put them in conflict with each other, as is often the
case, communication between them may hurt
organizational performance, not help it. Organiza-
tional structure and performance measurement must
be taken into account before opening the flood gates
and permitting the free flow of information between
parts of the organization1.
A manager does not have to understand
how a MIS works
Most MIS designers seek to make their systems as
innocuous and unobtrusive as possible to managers lest
they become frightened. The designers try to provide
managers with very easy access to the system and
assure them that they need to know nothing more
about it. The designers usually succeed in keeping
managers ignorant in this regard. This leaves managers
unable to evaluate the MIS as a whole. It often makes
them afraid to even try to do so lest they display their
ignorance publicly. In failing to evaluate their MIS,
managers delegate much of the control of the organiza-
tion to the system’s designers and operators who may
6 MANAGEMENT DECISION

have many virtues, but managerial competence is
seldom among them.
Let me cite a case in point. A chairman of a board
of a medium-size company asked for help on the
following problem. One of his larger, decentralized
divisions had installed a computerized production-
inventory control and manufacturing-manager informa-
tion system about a year earlier. It had acquired about
$2 m. worth of equipment to do so. T h e board chair-
man had just received a request from the division for
permission to replace the original equipment with
newly announced equipment, which would cost
several times the original amount. An extensive
justification for so doing was provided with the
request. The chairman wanted to know whether the
request was really justified. He admitted to complete
incompetence in this connection.
A meeting was arranged at the division at which I
was subjected to an extended and detailed briefing.
The system was large but relatively simple. At the
heart of it was a re-order point for each item and a
maximum allowable stock level. Re-order quantities
took lead-time as well as the allowable maximum into
account. T h e computer kept track of stock, ordered
items when required and generated numerous reports
on both the state of the system it controlled and its
own “actions”.
When the briefing was over I was asked if I had any
questions. I did. First I asked if, when the system had
been installed, there had been many parts whose stock
level exceeded the maximum amount possible under the
new system. I was told there were many. I asked for a
list of about thirty and for some graph paper. Both
were provided. With the help of the system designer and
volumes of old daily reports I began to plot the stock
level of the first listed item over time. When this item
reached the maximum “allowable” stock level it had
been re-ordered. T h e system designer was surprised and
said that by sheer “luck” I had found one of the few
errors made by the system. Continued plotting showed
that because of repeated premature re-ordering the item
had never gone much below the maximum stock level.
Clearly the programme was confusing the maximum
allowable stock level and the re-order point. This turned
out to be the case in more than half of the items on the
list.
Next I asked if they had many paired parts, ones that
were only used with each other; for example, matched
nuts and bolts. They had many. A list was produced
and we began checking the previous day’s withdrawals.
F o r more than half of the pairs the differences in the
numbers recorded as withdrawn were very large. No
explanation was provided.
Before the day was out it was possible to show by
some quick and dirty calculations that the new
computerized system was costing the company almost
$150 000 per month more than the hand system which
it had replaced, most of this in excess inventories.
T h e recommendation was that the system be re-
designed as quickly as possible and that the new equip-
ment not be authorized for the time being.
T h e questions asked of the system had been obvious
and simple ones. Managers should have been able to
ask them but—and this is the point—they felt them-
selves incompetent to do so. They would not have
allowed a hand-operated system to get so far out of their
control.
No MIS should ever be installed unless the managers
for whom it is intended are trained to evaluate and
hence control it rather than be controlled by it.
Designing an MIS
T h e erroneous assumptions I have tried to reveal can, I believe, be avoided by an
appropriate design procedure, one of which I shall now outline.
Analysing the decision system
Each (or at least each important) type of managerial
decision required by the organization under study should
be identified and the relationships between them should
be determined and flow-charted. Note that this is not
necessarily the same thing as determining what decisions
are made. F o r example, in one company I found that
make-or-buy decisions concerning parts were made only
at the time when a part was introduced into stock and
was never subsequently reviewed. For some items this
decision had gone unreviewed for as many as 20 years.
Obviously, such decisions should be made more often;
in some cases, every time an order is placed in order
to take account of such factors as current shop loading,
under-used shifts and delivery times from suppliers.
Decision-flow analyses are usually self-justifying. They
often reveal important decisions that are being made by
default (e.g., the make-buy decision referred to above),
and they disclose interdependent decisions that are being
made independently. Decision-flow charts frequently
suggest changes in managerial responsibility, organiza-
tional structure, and measure of performance which can
correct the types of deficiencies cited.
Decision analyses can be conducted with varying
degrees of detail, that is, they may be anywhere from
coarse to fine grained. How much detail one should
become involved with depends on the amount of time
and resources that are available for the analysis.
Although practical considerations frequently restrict
initial analyses to a particular organizational function,
it is preferable to perform a coarse analysis of all of an
organization’s managerial functions rather than a fine
analysis of one or a subset of functions. It is easier to
introduce finer information into an integrated informa-
tion system than it is to combine fine sub-systems into
one integrated system.
Analysing information requirements
Managerial decisions can be classified into three
types:
• Decisions for which adequate models are available
or can be constructed and from which optimal (or near
optimal) solutions can be derived. In such cases the
decision process itself should be incorporated into the
information system thereby converting it (at least
partially) to a control system. A decision model identifies
what information is required and hence what informa-
tion is relevant.
• Decisions for which adequate models can be
constructed, but from which optimal solutions cannot
be extracted. Here some kind of heuristic or search
procedure should be provided even if it consists of no
more than computerized trial and error. A simulation
of the model will, as a minimum, permit comparison of
proposed alternative solutions. Here, too, the model
specifies what information is required.
• Decisions for which adequate models cannot be
constructed. Research is required here to determine what
information is relevant. If decision making cannot be
delayed for the completion of such research or the
decision’s effect is not large enough to justify the cost of
research, then judgement must be used to guess what
information is relevant. It may be possible to make
SPRING 1968 7

explicit the implicit model used by the decision maker
and treat it as the second type of model.
In each of these three types of situation it is
necessary to provide feedback by comparing actual
decision outcomes with those predicted by the model or
decision maker. Each decision that is made, along with
its predicted outcome, should be an essential input to a
management control system, a point which I shall
return to later.
Aggregating decisions
Decisions with the same or largely overlapping
informational requirements should be grouped together
as a single manager’s task. This will reduce the
information a manager requires to do his job and is
likely to increase his understanding of it. This may
require a re-organization of the system. Even if such a
re-organization cannot be implemented completely what
can be done is likely to improve performance
significantly and reduce the information loaded on
managers.
Designing information processing
Now the procedure for collecting, storing, retrieving,
and treating information can be designed. Since there is
a voluminous literature on this subject I shall leave it at
this except for one point. Such a system must not only
be able to answer questions addressed to it; it should
also be able to answer questions that have not been
asked by reporting any deviations from expectations.
An extensive exception-reporting system is required.
Designing control of the control system
It must be assumed that the system that is being
designed will be deficient in many and significant ways.
Therefore, it is necessary to identify the ways in which
it may be deficient, to design procedures for detecting its
deficiencies, and for correcting the system so as to
remove or reduce them. Hence the system should be
designed to be flexible and adaptive. This is little more
than a platitude, but it has a not-so-obvious implication.
No completely computerized system can be as flexible
and adaptive as can a man-machine system. This is
illustrated by a system that is being developed and is
partially in operation (see Figure 2).
The company involved has its market divided into
approximately two hundred marketing areas. A model
for each has been constructed as is “in” the computer.
On the basis of competive intelligence supplied to the
senior marketing manager by marketing researchers and
information specialists he and his staff make policy
decisions for each area each month. Their tentative
decisions are fed into the computer, which yields a fore-
cast of expected performance. Changes are made until
the expectations match what is desired. In this way they
arrive at final decisions. At the end of the month the
computer compares the actual performance of each
area with what was predicted. If a deviation exceeds
what could be expected by chance, the company’s OR
group then seeks the reason for the deviation, perform-
ing as much research as is required to find it. If the
cause is found to be permanent the computerized model
is adjusted appropriately. The result is an adaptive man-
machine system whose precision and generality is
continuously increasing with use.
Finally, it should be noted that in carrying out the
design steps enumerated above, three groups should
collaborate: information systems specialists, operations
researchers, and managers. The participation of
managers in designing a system that is to serve them,
assures their ability to evaluate its performance by
comparing its output with what was predicted.
Managers who are not willing to invest some of their
time in this process are not likely to use a management
control system well, and their system, in turn, is likely to
abuse them.
Reference
1. S. S. Sengupta and R. L. Ackoff, “Systems Theory from
an Operations Research Point of View”, IEEE Trans-
actions on Systems Science and Cybernetics, 1 (Nov.
1965), pp. 9-13. provide a more rigorous discussion of
organizational structure and the relationship of
communications.
8 MANAGEMENT DECISION

project work/The most useful software for executives

25THE MOST USEFUL SOFTWARE FOR EXECUTIVES
Today’s executives must play many roles, but little is
known about how they do their job. One thing is for sure,
however, executives digest vast amounts of information.
Furthermore, their functions, as well as the way they
perfor m those functions, vary not only betwe en
organizations but also betwe en executives within
organizations.
The most useful software for executives must be flexible
and easy to use. It must enable the executive to digest and
manipulate vast amounts of infor mation from both
within and outside the organization. Most of all, it must
do so in a manner that diminishes the computer
inhibitions of executives.
Executive information systems (EIS) constitute a class of
software that fulfil these requirements. They are
graphical and colourful in nature, allow executives to
view infor mation in any level of detail and allow
executives to play out different “what-if ” scenarios
without involving other staff members.
Given the varied role of the executive and the
proliferation of the computer in the USA and throughout
the rest of the world, it would be short-sighted, if not
impossible, to call one product the most useful software
for executives. However, a class of software allows the
flexibility to make such a statement. Therefore, the
executive information system class of software is the
most useful software for executives.
The role of the executive
The role of the executive has taken on many facets.
Today’s executive must embody the skills of a
psychologist, engineer, accountant, financial analyst,
attor ney and many other professionals. Most of all,
however, the executive is a strategic planner. An
executive must have the perspective of not only the big
picture of his/her organization but the bigger picture of
his/her global market and the biggest picture of world
events and how they affect his/her organization.
Over the past 30 years, there have be en many tools
developed to aid the executive in his role. The Boston
Consulting Group urged the categorization of products
into their “portfolio planning” matrix, rating lines
as “stars”, “dogs” and “cash cows”, and investing
accordingly. Other, more quantitative methods also
flourished. Strategic planning departments began to
appear and professional strategic planners and
consultants were hired by many organizations. Often,
executives were given volumes of information, which
they rarely read or understood. In the end these
approaches did little to improve the quality of strategic
planning. As a result many planning departments have
been cut back severely or done away with completely.
With the advent of the personal computer and its user-
friendly software, many executives began using
programs like Lotus 1-2-3 and Microsoft Excel to collect
infor mation and project outcomes using “what-if ”
scenarios. Still, only about 20 per cent of today’s
executives have access to a computer; and most of them
feel that sitting down and typing information into their
databases is beneath them.
According to John F. Rockhart, director of the Center for
Infor mation Systems Research at MIT, “There is no
position in the organizational hierarchy that is less
understood than that of the senior executive”. Rockhart
continues, “The development of a computer-based
executive support system requires an understanding of
what it is that executives do”[1]. In general, the functions
of the executive can be broken down into the following
areas[1]:
● They (executives) review reports from their
subordinates on the activities of many areas of the
organization.
● They monitor news of the outside world.
● They meet with managers in the organization to
discuss operations and strategy.
The most useful software for
executives
Eric Chiusolo and Brian H. Kleiner
The merits of executive information systems
Industrial Management & Data Systems, Vol. 95 No. 10, 1995, pp. 25-28
© MCB University Press Limited, 0263-5577

26 INDUSTRIAL MANAGEMENT & DATA SYSTEMS 95,10
● They identify problems and opportunities and
form plans to capitalize on them.
● They lead the people who work for them to carry
out their goals.
● They do not systematically generate hard data in
the way that other segments of the organization do
(i.e. accounting).
● Each executive has a unique way of doing his/her
job.
Richard Crandall, president of Comshare Inc. a producer
of EIS software, notes: “Executives have no standard way
in which they look at information…However, a lot of
what goes on under neath is standard”[1]. There are
certain key items that are monitored in every business.
Sales, costs, capital expenditures, working capital and
cash flow are all common determinants of business
performance. Executives typically ask the following
questions[2]:
● How does present perfor mance compare with
budgets, predictions and trends?
● How does one division’s performance compare
with other divisions of the organization?
● How does the organization’s performance compare
with other organizations?
● Are there any discernible long-term trends?
To further underscore the executive’s role, the executive
must not only control but be seen to be in control of the
organization. Officers and board members have a further
legal requirement to ensure that all areas of an organi-
zation have been tended to and are financially sound.
In summary, the role of the executive varies depending on
the person and the organization. However, ne ed for
current and accurate information about the organization
and the world in general is common among all executives.
Furthermore, high-technology solutions have not been
accepted at the executive level. Indeed, what is the most
useful software for executives? Is there a single one? Can
there be a single one?
While there is a most useful software for executives, there
is not a single one. Rather, it is a new class of software
called the executive infor mation system (EIS – also
referred to as the executive support system).
The executive information system
Frederick A. Wang, former president and CEO of Wang
Laboratories, commented that “managers spend more
than 40 per cent of their working hours looking for
information…computers have automated only about
5 per cent of office information. Almost all of the other
95 per cent is on paper”[3].
Better information leads to better decisions. As rapidly as
both market and world conditions change, an
organization must master its information requirements to
achieve significantly better perfor mance. The EIS
evolved from the ne ed to control the financial
perfor mance of an organization. As time passed it
became clear that other factors, such as the rate of
inflation and the level of competition, had a clear impact
on an organization’s performance. Therefore, information
from outside the organization should be included in EIS.
There is no one definition for an EIS. Generally, however,
an EIS is a system that delivers comprehensive
information from within and outside the organization to
executives in a simple, easy-to-use format and does so in
a timely manner. Further more, it can deliver the
information as summaries, exceptions, charts, graphs
and in whatever level of detail the executive requires. It
delivers its infor mation in a colourful and easily
understood manner (i.e. exceptions would be coloured in
red). David DeLong of MIT has classified EISs into three
types[4]:
(1) Office support – an extension of office automation
including word processing, spreadshe ets,
electronic mail and calendars.
(2) Planning and control of operations. Monitoring
performance and assisting in strategic planning.
(3) Inquiry and analysis to enhance an executive’s role.
According to Tim O’Shea of Seamark Consulting, an EIS
should “reduce administrivia, provide managers with key
variables and operating indicators without paper just like
an airline cockpit. They should also greatly enhance
communications among the executive group. Finally, they
should allow executives to ask sensitive questions
without involving others like – What would happen if I
shut down Plant X?”[4].
An EIS should include four main characteristics[2]:
(1) An EIS should replace paper reports.
(2) An EIS should have the ability to provide the
information needed for informed decision making
both from within and outside the organization in a
timely manner. Information should provide insight
to, but not be limited to, marketing, production,
personnel, competitors, share prices and economic
conditions.
(3) Ease of access. It should enable non-technical
executives to obtain required data quickly and
easily.
(4) An EIS should satisfy the executive’s desire for
processed information. Processed information is
that which is presented in a quickly readable
manner (i.e. charts, graphs, colour highlights, etc.).
EISs generally start from an instr ument panel. The
instrument panel is similar to a menu, except it illustrates

27THE MOST USEFUL SOFTWARE FOR EXECUTIVES
the choices to be made. The key to an EIS is to provide
g raphic, colourful displays of information which an
executive would normally have to extract manually from
reports, newspapers, telephone conversations and face-
to-face encounters. Furthermore, it must be easy to use. If
executives feel inhibited about using a system, chances
are they will never turn it on.
An important feature of an EIS is what Comshare calls
the ability to “drill down”. Drilling down is simply
looking behind the numbers. For example, executives
may display bar g raphs illustrating sales betwe en
divisions and notice that one division is lagging far
behind the rest. With the click of a mouse, a computer
pointing device, they can view the actual numbers that
made up sales for that division. If they wish to continue,
they can look at the customers who have purchased or
those who have not purchased. They could also look at
the productivity of the salesforce or the output of the
factory. The point is, they start with a simple overview
and have the option of drilling down to view the numbers
behind the story. In a conventional environment,
executives would be at the mercy of lower and middle
managers for such information, often not getting the
right information until it is too late – if at all!
Another important feature is the ability to show compar-
isons. Most EISs will show data, either graphically or in
detail, and compare them to such benchmarks as a bud-
get, a previous period, or any other comparison the exec-
utive chooses. Still another important feature is the
ability to manipulate news data as if they were theirs.
Many of the EISs can download data from companies like
the Dow Jones News Retrieval Service. Once in the EIS,
executives can manipulate the data as they see fit.
The technical side of executive information
systems (without being too technical)
An EIS must be customized to fit the needs of the organ-
ization as well as the executive using it. Many of the EISs
in use today were written in-house. GTE wrote a personal
computer- (PC) based system in six we eks for only
$14,000 – some $46,000 under budget[5]. Others were pur-
chased from the more than 15 companies offering EIS
software and tools. These off-the-shelf packages range
from $2,000 to $300,000. Most companies, however, spend
$100,000 to $150,000 per installation on EISs. It must be
noted however, that, as illustrated earlier, an EIS is a
system that is designed to fit the individual needs of
executives and their organizations. Therefore, any off-the-
shelf package will have some modifications before the
installation is complete.
There are thre e types of systems: mainframe and
ter minal, PC-based, and co-operative processing
(seamless PC-mainframe integration). The mainframe
and terminal approach goes part of the way to meeting
the requirements on an EIS. Its advantages are system-
wide data integrity and distribution (all executives on the
system see data from the same database), and integration
with electronic mail – a vital feature for executive use. Its
disadvantages are its cost and the slow response time due
to the graphical displays.
The PC is known for its graphical capabilities and its
user-friendly interface. However, PC-based systems can
have trouble processing the large amounts of data
necessary in an EIS. The data in an EIS is actually stored
at a very detailed level. It is displayed, however, in the
form of a summary, involving thousands of computations
and data records. If it is displayed graphically, there are
even more computations. In addition, the PC-based
system does not provide system-wide data integrity.
Co-operative processing takes advantage of both
mainframe and PC technology. For example, data storage
and manipulation can be performed on the mainframe,
taking advantage of its processing capabilities and
providing system-wide data integrity. Information could
then be fed to the PC where it can be presented in a
simple, g raphical manner (i.e. a pie chart). In this
configuration EIS software resides on both the
mainframe and the PCs in the system. This is by far the
most desirable configuration for an EIS.
Executive information systems packages
The leading supplier of EIS packages is Comshare Inc. of
Ann Arbor, Michigan. Comshare released Commander
EIS in 1985. Commander is an example of a software
utilizing co-operative processing via either IBM or DEC
mainframes and IBM compatible PCs. It has four basic
components:
(1) The Briefing Book: a series of preformatted status
reports that are periodically downloaded from the
mainframe to the PC.
(2) Execu-View: enables executives to analyse and
investigate data from a number of different
perspectives.
(3) Retrieval from outside sources: allows executives
to retrieve information from a number of outside
sources including Dow Jones News Retrieval
Service.
(4) Electronic mail: the ability to send messages to
other executives without leaving the Commander
environment.
Other major suppliers are Pilot Executive Software of
Boston, Massachusetts and their Command Center
software, Action Technologies of Emeryville, California
and their Coordinator Software and Forthright Systems
of Sunnyvale, Califor nia and their Vantage Point
Software. Each of these suppliers has differentiated its

28 INDUSTRIAL MANAGEMENT & DATA SYSTEMS 95,10
software packages in some way. For example, Forthright
Systems’ Vantage Point is controlled via remote control.
They all, however, attempt to provide an easy-to-use
venue from which executives are able to receive
infor mation and accomplish the tasks outlined
previously.
Executive information systems success stories
A number of top performing organizations have installed
EIS. The list includes ABC News, Bank of Boston, Bristol
Meyers, Chase Manhattan Bank, Citizens & Southern,
ConAgra, Dayton-Hudson, Du Pont, Duracell, Mrs Feilds
Inc., GTE, General Electric, General Foods, General
Motors, Gillette, Grumman, Kraft, John Hancock, Hertz,
Johnson & Johnson, Kraft, Lever Brothers, Lockheed,
Marine Midland Bank, Metropolitan Life, Monsanto,
Motorola, Oscar Meyer, New England Mutual Life, New
York Life, Nynex, J.C. Penney, Pan-Am, Phillips
Petroleum, Polaroid, Public Service Electric and Gas of
New Jersey, Richman Gordon Stores, Southwestern Bell,
TRW, Union Carbide, Unum Life, Wang Laboratories,
Westinghouse, Xerox and many others.
During the presidential campaign of 1988, ABC News
anchormen Peter Jennings and David Brinkley used an
EIS for on-the-air access to detailed information. In the
past they would have had to sift through stacks of 4 × 6
cards for their notes[5].
The response at Hertz was phenomenal. Comshare’s sales
presentation to Hertz president Craig R. Koch lasted only
five minutes. Koch interrupted and said he loved it! Soon
afterwards the system arrived. Today at the Hertz
Corporation, managers, as well as executives, have access
to the EIS. They can access market shares in a contested
area, gauge price levels in relation to costs, project the
rental volume ne eded to offset a price decrease, and
measure cost against historical data. Furthermore, they
are able to r un any one of a number of what-if
scenarios[6].
There are numerous stories like these. Stories of
improved communication, more infor med decision
making and, most of all, acceptance at the executive level.
In summary, the role of the executive varies among both
organizations and executives. Therefore, there cannot be
a single most useful software for executives. EIS provide
a flexible, easy-to-use venue for executives to receive and
manipulate the information vital to the success of their
organization. Executive information systems are the
most useful software for executives.
References
1. Weter, T.R., “Tools at the top”, Industr y Week,
21 November 1988, pp. 41-4.
2. Shoebridge, A., “EIS: friend or foe?”, Accountancy,
October 1988, pp. 150-1.
3. Wang, F.A., “The great paper chase”, Industry Week,
20 March 1989, p. 48.
4. Rees-Evans, H., “Top management transformed as EIS
arrives”, Accountancy, April 1989, pp. 143-4.
5. Davis, S.G., “Can stand-alone EISs stand up?”,
Datamation, 1 July 1990, pp. 164-5.
6. McCartney, L., “How ESS helps Hertz managers out in
front”, Business Month, July 1989, pp. 46-7.
Further reading
Armstrong, D., “The people factor in EIS success”, Datamation,
1 April 1990, pp. 73-9.
Betts, K.S., “Executive support systems: the electronic
facilitator for better decision making”, Modern Office
Technology, June 1990, pp. 88-9.
Daft, R.L. and Lengel, R.H., “Organizational infor mation
requirements, media richness and str uctural design”,
Management Science, May 1986, pp. 554-69.
DeLong, D.W. and Rockhart, J.F., Executive Support Systems:
The Emergence of Top Management Computer Use, Dow
Jones-Irwin, New York, NY, 1988.
Dixon, A., “Software support for executive role-change”,
Accountancy, July 1988, pp. 164-5.
The Economist, “Bringing up bosses in the IT age”, 23 April
1988, pp. 67-8.
The Economist, “Decisions, decisions”, 22 July 1989, pp. 64-5.
Gauthier, M.R., “Executives go high-tech”, Business Month,
July 1989, pp. 44-7.
Harvey, D., “Executives switch to EIS”, Accountancy, February
1989, p. 130.
Langan, P.A., “At last, software CEOs can use”, Fortune,
13 March 1989, pp. 77-83.
Madlin, N., “Executive information systems.”, Management
Review, August 1986, pp. 21-2.
Myers, E.D., “EIS provides critical details – without paper”,
Administrative Management, March 1988, pp. 23-6.
Robins, G., “Exec info systems”, Stores, May 1989, pp. 29-36.
Eric Chiusolo and Brian H. Kleiner are in the Department of Management, School of Business Administration and
Economics, California State University, Fullerton, California, USA.