s * f ., Aweb.mit.edu/smadnick/www/MITtheses/04409713.pdf · A Framework for Management Information Systems Evolution And Case Study TABLE OF CONTENTS Page Abstract 2 Acknowledgements

- 1-

A FRAMEWORK FOR MANAGEMENT

INFORMATION SYSTEMS EVOLUTION

AND

CASE STUDY

by

PETER FRANCIS DIGIAMMARINO

B.S., University of Massachusetts(1975)

SUBMITTED IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE

DEGREE OF MASTER OF

SCIENCE

at the

MASSACHUSETTS INSTITUTE OF

TECHNOLOGY

June, 1977

Signature of Author .........................................Alfred P. Sloan School of Management, May 12, 1977

Certified by ..................................................Thesis Supervisor

Accepted by ................................................Chairman, Departmental Committee on Graduate Students

5 r' 1

s f * * . A ,

A£1

'A

-2-

A FRAMEWORK FOR MANAGEMENT

INFORMATION. SYSTEMS EVOLUTION

AND CASE STUDY

by

PETER FRANCIS DIGIAMMARINO

Submitted to the Alfred P. Sloan School of Management on May

12, 1977 in partial fulfillment of the requirements for the

degree of Master of Science.

ABSTRACT

This thesis describes several concepts relating to computerbased management information systems. Environmental factorsand guidelines that lead to the evolution of a successfulsystem are presented. A comprehensive framework for manage-ment information systems evolution is then proposed alongwith an example of its use through a case study.

Use of the proposed framework demonstrates its utility in anactual case, without leading to a definitive statement con-cerning its universal applicability.

Thesis Supervisor: JOHN J. DONOVAN

Title: PROFESSOR OF MANAGEMENT SCIENCE

Thesis Advisor: STUART E. MADNICK

Title: ASSOCIATE PROFESSOR OF MANAGEMENT

-3-

ACKNOWLEDGEMENTS

This thesis could not possibly have been completed

without the magnanimous support and assistance received from

friends, relatives, advisors and colleagues too many to list

in entirety. Professor John Donovan provided invaluable

guidance from the beginning right through to the very end.

Paul Schaller, Lee Freeman, Luther Goodie, and Edward McCabe

all deserve special recognition for their help with the case

study and their support and constructive comments throughout.

My brother, Paul, also receives credit for his valuable

assistance. My parents, for giving endless support and for

sharing their worldly wisdom with me have earned a long

awaited word of thanks. My wife, Margaret Owen, with whom

I have begun to share the pleasures and pains associated with

pursuit of both a career and happiness, will now, finally,

experience life divorced from academia. For her I reserve

the highest form of gratitude.

-4-

A Framework for ManagementInformation Systems Evolution

And Case Study

TABLE OF CONTENTS

Page

Abstract 2

Acknowledgements 3

Table of Contents 4

List of Illustrations 6

Chapter 1 Management Information Systems 7

1.1 Concepts and Misconceptions 9

1.2 Frameworks for MIS Evolution 12

Chapter 2 Proposed Framework 14

2.1 Needs Assessment 16

2.2 Design 26

2.3 Approach 32

2.4' Actualization 39

2.5 Evaluation 42

2.-6 Summary of Framework 45

Chapter 3 Case Study 47

3.1 Needs Assessment 47

3.2 Design 61

3.3 Approach 63

3.4 Summary of Case Study 74

Bibliography 81

-5-

Page

Appendices 86

A. Organization of Departmentof Education 86

B. Organization of Bureau ofInformation Systems 87

C. Current Subsidy Formula 88

D. Three Proposed Changes toSubsidy Formula 92

-6-

TABLE OF ILLUSTRATIONS

Figure Title

1 Proposed Framework

2 Evolution of A Management InformationSystem

3 Gorry and Scott Morton Framework ofDecision Making

4 - Information Characteristics by DecisionArea

5 Current Subsidy System

6 Proposed Subsidy System

7 District Data Base

8 Subsidy Components by County and District

9 Frequency Distribution by District

10 Macros Used to Compute Subsidies

11 Commands to Calculate Subsidy Allotments

12 Macros Used to Compute SubsidieslAlternative Formula)

13 Subsidy Components by County and Dietrict(Alternative Formula)

14 Frequency Distribution by District.(Alternative Formula)

-7-

1 MANAGEMENT INFORMATION SYSTEMS

Computer based Management Information Systems (MIS) play

an important role in virtually all contemporary organizations.

A definition of management information systems, put forth by

Kennevan,(40) summarizes the key dimensions of the concept:

MIS - "An organized method of providing past,present and projection information re-lated to internal operations and externalintelligence. It supports planning, con-trol and operational functions of an org-anization by furnishing information inthe proper time frame to assist in thedecision process.

A summary of issues relating to management information systems,

eminating from Kennevan's attempt at a definition, prefaces

the body of this paper in order to establish common ground

for the unveiling of ideas relating to them.

An MIS is used to process data for some purpose in an

organization. Data used for a specific purpose is referred

to as "information". This purpose is one that probably existed

before an MIS was present and one that would continue were an

MIS nonexistent or made unavailable. The existence of an

MIS is justified only to the extent that the functions or

activities to which it applies are made more efficient, more

effective or simply easier to perform as a result of its

presence. An MIS is a service to its users and is not a

product in itself or, stated in another way, the MIS is a

-8-

means to an end and is not an end in itself.

Kennevan highlights the realm of influence of an MIS.

Support of planning, control and operations implies an impact

on all phases of organizational activity. In reality, however,

a given MIS will.probably be oriented more toward a particular

one of Anthony's (4) three divisions of business functions

(planning, control, and operations) than another.

An MIS is capable of storing, retrieving and processing

historical data, assimilating present data and projecting

information about the future. Information internal and

external to the organization may be handled by the system.

There was a time when it was envisioned that an MIS would

be capable of managing all information related to an organization

in any way. An MIS of this sort is often referred to as

a "Total MIS". The concept of the "Total MIS" has been much

criticized in the literature (1,15,31,39,52). Contemporary

systems are oriented to specific portions of organizational

activity and deal with only a subset of all possible internal

and external information.

Kennevan suggests that an MIS provides timely information

to be used in decision making. In addition there is a notion

of supplying information in the format most appropriate to a

given situation and a corresponding means of insuring that

the information is delivered to the right place.

These broad characterizations of an MIS yield an ideal-

-9-

istic perception of a system that aids in all phases of

organizational activity by supplying the right information,

to the right people, in the right format and at the right

time. This abstraction of an MIS is a useful conceptualization

as it accurately depicts the important dimensions of such

systems.

The growth in scope, breadth and complexity of management

information systems has given rise to a vast array of new

technical and operational problems, particularly in the

early stages of MIS development. The ability to deal with

these problems will determine whether or not information systems

will ever reach their predicted potential utility in the

business world.

1.1 CONCEPTIONS AND MISCONCEPTIONS

Management Information Systems have proliferated at an

astronomical rate in recent years, primarily as a result of

increasing technological capabilities and decreasing costs

of computer hardware. There appears to be an endless stream

of activities to which an MIS can be applied. This enthusiasm

is personified by Ackoff (1) when he refers to a "romantic

relationship between analysts and the most glamorous instrument

of our time, the computer." The analyst must remember, however

that the goal is to institute a vehicle capable of providing

more effective and efficient operations and not simply to

computerize the current system.

Ackoff points to several misconceptions that have been

the source of misguided attempts to institute management

information systems. Some of his revelations are considered

here as they are appropriate caveats to any attempts to bring

an MIS to life:

"Management suffers from a lack of relevantinformation in most important decision making."

This once accepted tautology is portrayed as a false pretense

by Ackoff (and later by Argyris (6)). A more accurate version

of the concept that is supported in this thesis runs as follows:

"Management suffers from an abundance ofirrelevant information in most importantdecision making."

The MIS designed to provide management with all possible in-

formation is bound to aggravate rather than ameliorate the

plight of decision makers. An MIS should be designed to pro-

vide filtered ACCESS to relevant information rather than being

the source of endless and useless reports.

"Designers of management information systemscan best determine users' information needsby asking him what information he requiresto make decisions."

The problem raised with this statement is that users

often do not know what information they need (on a regular

or ad--hoc basis) until they need it. Both Ackoff and Burg-

staller (10) point out that traditional attempts to discover

user needs through personal interviews and questionnaires

-11-

leads to confusing and often contradictory results. Users

will generally either play it safe and ask for "the works"

(in which case the analyst responds by nobly trying to pro-

vide him with more than everything) or the decision maker will

claim that he already has all the information he can possibly

use, leaving MIS designers with no recourse but to guess at

what information to provide.

The final warning concerns the MIS users' intimacy with

the system. Traditionally users have been shielded from the

mechanics and logic of the MIS in order to protect them from

having to learn its esoteric details. Such a relationship

allows the user to be manipulated by the system. As a result,

the MIS cannot be adequately controlled or evaluated by the

user. Users ought to be comfortable with their MIS and should

be encouraged to ask questions concerning its processing

and results to insure correctness and relevance to the tasks

at hand. The introduction of an MIS into an organizational

environment can be an extremely emotional and complex problem

in human engineering. A high degree of interpersonal competance

is demanded of the MIS administrator in order to lead a smooth

transition to a new system.

Many authors have identified and made frequent reference

to four factors which, to a large extent, determine the fate

of even a superbly designed system (6,14,27,39,43,52):

-Top management support

-Clear statement of system objectives

-12-a

-Active and continuous user involvement

-Minimal degree of complexity and changeto organizational activity-

Empirical evidence has shown that when these factors are entirely

ignored, a system is sure to fail. "Successful" systems are

found to have been concerned with at least some of these factors.

In the framework proposed in Section 2, these issues play an

integral role in MIS evolution.

1.2 FRAMEWORKS FOR MIS EVOLUTION

Several frameworks and models that attempt to portray

the process of MIS evolution have appeared in the literature

(2,7,8,12,16,22,23,24,26,32,50,54). (Traditionally this

process has been labeled "MIS design" or "MIS implementation".

Here, and throughout this thesis, the term "MIS evolution"

is used in order to convey a more "start to finish" flavor

to the subject.) These have primarily been produced by

academicians who have tracked successful and unsuccessful

management information systems in order to identify factors

that lead to a successful system. Their frameworks represent

an effort to illustrate linear step sequences that provide

a means of visualizing MIS evolution from a global perspective

but fail to provide adequate guidelines for future endeavors.

A characteristic common to most frameworks found in

the literature is that they leave no recourse at each step

but to go on to another step. This has negative impact if

-13-

at some point it may be more appropriate, for one reason

or another, to abort the effort entirely. Few models

incorporate explicit checkpoints which call for reexamina-

tion of needs, objectives, feasibility and costs in order

to enable either management, user or analyst to terminate

the project.

Guidelines which account for the dynamic nature of the

evolutionary process and which focus attention on critical

phases of evolution are needed in order to give a coherent,

structured, and parsimonious foundation for MIS development.

A framework encompassing these guidelines must consider

communication between analysts, designers and users; it

should reflect a concern for human emotional behavior and

the importance of power; as well as document the steps

leading to MIS development. Finally, a set of guidelines

must be validated with repeated use to demonstrate that it

has utility'in the real world.

The framework presented in Section 2 is an attempt to

impose a structure that captures these essential points and

that will be useful in actual cases. Just as there is no one,

universally accepted definition of management information

systems, however, there is no single framework or set of

guidelines that are applicable in all instances. In essence,

then, this is a presentation of what appears to be a reason-

able methodology for MIS evolution in many cases, and evi-

dence that this is true in a particular application.

-14-

2 PROPOSED FRAMEWORK

There are five major divisions or phases that comprise

the proposed framework (see figure 1). Within each phase

there is an associated set of activities and outcomes that

determine the function of that phase in the evolution of an

MIS.

G NEEDS DESIGN PPROACH ACTUALIZATIOND VALUATIONASSESSMEN

Figure 1Five Phase in MIS Evolution

The Needs Assessment (also called Pre-Design) phase

includes: becoming familiar with the user environment;

identifying problems, inefficiencies and bottlenecks; and

specifying characteristics and functions of a more desireable

environment. In the Design phaseobjectives and characteris-

tics of a new system are determined, and a plan for its

implementation developed. Approach refers to the identifi-

cation of and selection from available hardware and soft-

ware technology, breadboarding of a system prototype and

preparing to embark on the implementation effort. Actualiza-

OUTCOME I

NEEDS ASSESSMENT

OUTCOME

**'" AN

NJECTWES O

NEW SYSTEM

ACTIVITY OUCOME

KAROWARE &SOFTWARE

AWJLAB.E TOSUPPORT

DESIGN APPROACH

EVOLUTION OF A MANAGEMENT INFORMATION SYSTEM

FIGURE 2

ACTIVITY OUTCOME

EVALUATION

-16-

tion includes programming and implementation of system

components, installing subsystems as they become ready,

testing, debugging, documentation and initial use. User

feedback and comparison to stated objectives provide the

basis for the Evaluation phase.

The framework is enhanced by extensions made along

three dimensions. First, each phase is further divided

into steps. Second, each step is portrayed as a combina-

tion of both an activity -and the result of an activity (or

an outcome) that is used as input to the next step. Finally,

checkpoints are strategically implanted to allow escape

from the process at key stations. A representation of the

enhanced framework appears in figure 2 and will serve as the

basis for discussion throughout the remainder of this

section.

The phases of evolution are now addressed in detail.

Certain vocabulary -is employed throughout the discussion.

The term "Analyst" refers to the individual or team of

individuals responsible for monitoring and guiding MIS

eVolution. "Users" or "Clients" are the individuals who

will employ or benefit from the system when it is completed.

"Management" may also be users but more generally repre-

sents the supervisors or overseers of users. "Top Manage-

ment" are the highest level of managers exercising direct

control over the user environment.

2.1 NEEDS ASSESSMENT

-17-

The objective of the model's first phase is to insure

that the correct problem is addressed. It is difficult to

determine with certainty that one problem is any more

"correct" than another in terms of mandate for change. The

issue is, more precisely, that systems designers and

analysts must be working with a set of problems that are

in accord with those perceived as in need of attention by

individuals who work in the area. It is equally important

that the analyst's assessment of needs verify those perceived

by users. Initially, the analyst's diagnosis will often

deviate significantly from the user's assessment. For this

reason the analyst must be familiar with existing operations

from the user's point of view. The analyst who deals with

users, rather than exclusively with managers of users, learns

about needs from the proper perspective and will be more

likely to end up addressing the right problems.

STEP 1

In Step 1 the analyst become intimately familiar with

the prevailing user environment. This requires spending

considerable time and effort getting to know what duties

are performed, how they are accomplished, what decisions are

made, and why different functions are important. These

activities should result in a coherent and cogent descrip-

tion of the current system. This is referred to, in

literature, as formulating a "descriptive model" (27).

-18-

ACTIVITY OUTCOME

DESCRIPTIONEXAMENE OFEXISTING EXISTING

'ENVIRDNMENT ENVIRONMENT

(DescriptiveModel)

STEP,- I

With the construction of this model the analyst acquires a

thorough understanding of the existing environment.

Users play an important role from the outset of MIS

evolution. The analyst's primary source of information is

the user. When a descriptive model is derived, the analyst

is encouraged to confront the user with an interpretation of

the environment and to incorporate criticism and suggested

modifications if necessary. Since the initial system serves

as the basis for change, it is critical that the descriptive

model represent an accurate and realistic summary of the way

duties are currently performed. User validation of the model

insures a higher degree of accuracy.

-19-

Unfortunately there are no procedures, short of becoming

a part of the user environment for an extended period, that

guarantee the analyst will acquire the knowledge needed to

formulate a descriptive model. The most popular approach is

to conduct a series of personal interviews. As mentioned

earlier and as elaborated by Rockart (52) and Burgstaller (10)

the questions asked in an interview can do more harm than

good, and often result in contradictory or confusing informa-

tion. An alternative or adjunct to an interview incorporates

the use of an instrument or questionnaire designed to help

elicit information from the client. Questionnaires have

only recently begun to emerge (see 5, 10, 33 for discussion

and examples) and are largely untried and untested.

In general it has been determined that questions which

ask (either in person or via an instrument) "What informa-

tion do you need?" tend to emit vague and often meaningless

responses. Burgstaller indicates that more information is

gained from responses to such questions as: "What do you

(the user) do?" followed by "What important decisions do

you make?" and finally "What information do you require to

make these decisions?". The latter leads more readily to

substantive discussion concerning user functions and cor-

responding information needs.

The analyst, in order to be successful, must initiate

information gathering activities such as: interviews,

questionnaires, group discussions, direct observation and

-20-

investigation. Regardless of the techniques used the results

of these activities should include the following outcomes:

1. establishment of working relationshipbetween user and analyst

2. realistic model or description ofexisting environment

3. statement of user information requirements

STEP II

The descriptive model of the environment should now be

studies to uncover inefficiencies, inconsistencies, redun-

dancies, bottlenecks and other problems with the existing

system.

ACTIVITY OUTCOME

ANALYZE DENTIFICATIONEXISTING 1 OF PROBLEMSENVIRONMENT INEFFICIENCIES

ETC.

STEP - II

The analyst must pull together user comments and combine

them with results from his own systematic evaluations to

compile a list of problems. At this point, no solutions

should be proposed. This is strictly a process of problem

identification. A list of all identified problems should be

drawn up, as this will form the basis for determining the

objectives and characteristics of a better system, in the

next step.

The analyst should take care to separate problems from

one another and to recognize that some problems are, in fact,

-21-

the cause or result of others. The objective of this

activity is to isolate each issue in its most basic form

so that processes and functions requiring attention are

explicitly identified.

Once compiled, the list of problems should be discussed

with users in order to allow them to add or delete items as

well as to speak out on the relative importance of each.

Concensus amoung analyst and users results in a final list

that contains a full accounting of problems in a prioritized

order. This approach will stimulate discussion and draw

attention to areas that will later be the focal point of a

new system.

In the second step, then, the analyst: engages in a

systematic analysis of the existing environment from the

descriptive model, compiles a list of problems in prior-

itized order, and discusses this list of problems with the

user population. The result of these activities is a menu

of problems that will be addressed in the next step.

STEP III

The activities in Step III use the list of problems

and an understanding of the business environment to derive

a statement of how the existing system would appear if all

the noted problems were resolved.

-22-

ACTIVITY OUTCOME

ASSESS DESCRIPTIONOF

EXISTING -MORE DESIREABLEENVIRONMENT

ENVIRONMENT (NormativeModel)

STEP - III

The result is a.picture of a "better world" or what is more

commonly referred to as a "normative model" (38). The

normative model serves as the basis for formulating explicit

goals and objectives of a new system. It is a statement of

how functions would be performed, decisions made, information

received, retrieved and transmitted in an ideal world.

There is bound to be more than one reasonable proposal

for the way things ought to appear in a perfect system. All

alternatives should be dutifully considered. If more than

one procedure appears to be warranted then perhaps a mechan-

ism for including multiple approaches is required. For

example, if certain information is needed in both a regular

and ad-hoc basis by different users then both avenues of

access may be arranged in a more desireable system.

In order to maintain a perspective that will facilitate

in this procedure, it is useful to determine the generic

nature of the problem. Two mechanisms have been developed

to assist in this effort. The first is a framework of

decision making presented by Gorry and Scott Morton at

MIT (28) and later supported and extended by several other

-23-

authors (21, 39, 45). Figure 3 shows a taxonomy of

decision types identified by their characteristics along

two dimensions: degree of structure and context of organi-

zational activity.

DECISION CATEGORIES

Strategic Management OperationalPlanning Control Control

Plant . Task InventoryStructured Location Scheduling Monitor

Semi- Capital Product BondStructured Acquisition Budgets Trading

Merger; Hiring R&DUnstructured Acquisition Managers Activities

Figure 3

Gorry/Scott Morton Frameworkof Decision Making

DecisionTypes

-24-

'Abross the top of the figure are Anthony's (4) three

decision categories (strategic planning, management control,

and operational control) and the rows correspond to Simon's

(57) classification of decision types. Gorry and Scott

Morton point out that traditional management information

systems have tended to cluster in the structured/operational

end of the continuums,

The-usefulness of the Gorry-Scott Morton framework here,

is in its ability to; first, provide a perspective to the

problem area; second, to help identify, in general terms,

the likely characteristics of the problem area and its

position relative to the short and long term activity of the

organization; and third, to help determine the probability

that similar situations have been addressed by others, It

is useful to search out such cases in order to study their

utility in other environments.

The second mechanism is presented by Keen and Scott

Morton (39) and involves the description of information

characteristics according to the decision area (see figure

4). Examining information needs along these dimensions

provides insight that can be used to generate specifications

of a normative model. Notice that each dimension is por-

trayed as a continuum. Different uses of the same informa-

tion require that information to meet different standards

along the various dimensions.

-25-

Strategic Management OperationalPlanning Control Control

Accuracy low ( _ _ high

Level of Detail aggregate ( : detailTime Horizon future / >,present

Information Frequency of Use infrequent ( ) frequentCharacteristics Source external ( internal

Scope wide ( - narrow

Type qualitative < ') quantitative

Age older : : current

Information Characteristics by Decision Area

Figure 4

Some MIS experts argue that the normative model should

be constructed without the aid of a descriptive model. In-

stead of building a descriptive model, followed by a normative

model and then determining how to change the descriptive into

the normative; one could ignore the way functions are CURRENTLY

performed and deal only with the way things SHOULD be performed.

This strategy manages to avoid simply computerizing the current

system because the current system is never studied. Under-

standing the manner in which functions are currently per-

formed is a basic step in the framework presented here. If

the normative model is eliminated or ignored it is still pos-

sible to construct an MIS, provided that there is a (manual)

system to start with, Whether or not to include the normative

model and if so whether or not to preceed it with a descrip-

tive model is highly situation dependant. There are occasions

when excessive tampering with existing methods are not possible

and only mechanization of already inbread procedures is

tolerable (See (55) for an example), Conversely, there are

-26-

times when prevailing operations are so blatantly counter

productive that there is nothing to be gained from formulating

a description of current activities, The general case is pre-

sented here Cusing both descriptive and normative models in

sequence) with the. understanding that, on occasion, one or

the other is best left unused,

2The activities that lead to a normative model and a

specification of information characteristics are: design of

a system in -which the problems identified in step II are

resolved; information involved along several dimensions; and

efforts to locate and study similar systems that exist

elsewhere.

fonstruction of the normative model is the last step in

the :Needs Assessment phase. The combined objective of the

activities and outcomes making up this phase have been to

acquire a first hand familiarity with the user environment;

to know and understand prevailing functions, decisions and

activities; to identify problems; and to specify the

characteristics of a more desireable system. Taken together,

these steps are an organized means of establishin a basis

for hange, and steps to transform the current system into

one that is more desireable can now begin within the context

of Ilentified needs,

2.2 JESIGN

In this phase, results from Needs Assessment activities

are used to construct a viable system design and a plan of

-27-

action to see that a new system will be successfully com-

pleted. Throughout this phase it is again critical to

maintain extensive interplay between user and analyst. For

this reason, the formation of a "design team" is advisable,

Such a team includes at least one analyst and at least one

user from the target population, The user plays an active

role in the design process and must be capable of speaking

on behalf of his constituency, In addition, he will help

acquire new information as it is needed and is at least

partially responsible for keeping other users up to date as

to the progress of the design process. (A comprehensive

discussion of the MIS team concept is presented by Alloway

(4)).

STEP IV

The design team's first task is to examine the normative

model in order to explicitly state the goals and objectives

of the new system.

ACTIVITY OUTCOME

ANALYZE GOALS ANDNORMATIVE _ OBJECTIVES

MODEL OF NEWSYSTEM

STEP - IV

These statements detail what the system will do, what char-

acteristics the new system will take on and how it will be

used. The descriptions should be as specific as possible

in order to give a complete picture of the expected results,

-28-

Two important missions await the team once a set of

system objectives have been determined. The specifications

must be presented to top management for their approval and

support followed by a similar presentation addressed to

users.

Top management support has been identified earlier as a

primary determinant of system success. Management must be

convinced that there is a clear statement of purpose

(another prime contributor to success), that objectives are

both realistic and beneficial to the organization and that

the proposed system will be an asset to the organization,

Top management support alone does not guarantee

success. General Motors', Chevrolet division, found that

even though ton management vigorously and enthusiastically

supported the development of a Corporate Information System

(CIS), the system was less than a success primarily because

only upon completion were users consluted to test if design

objectives were useful (39, 53). Users too must be given the

opportunity to react to statements of intent prior to system

design. Valuable feedback may be obtained as well as

increasing the likelihood of formulating an acceptable

design.

The generation of objectives is an iterative process.

Initial specifications may meet with disfavor or may require

alteration and enhancement before approval and support are

secured. Once established, the objectives will be used

-29-

throughout the rest of the evolutionary process to judge

whether or not the system is developing according to plan.

Upon completion, the end product will be correlated with

objectives to help reach a verdict of system success or

failure.

The first evaluation of the project's future is

conducted prior to planning a definite course of action,

If the objectives are such that either there is no way to

achieve them or if it would take an inordinate investment of

personnel, time and dollars to do so, then there is cause

for concern. In either of these two cases it is wise to

scale down the extent of the proposed system so that it is

possible to complete within a reasonable budget using

existing technology. In the event that this is impossible

to do, the system may best be postponed. It is the role of

the analyst to provide the design team with an accurate

assessment of costs and technologies that will be necessary

to see the system through.

It can happen that a decision to abandon the system

will have to be made. .If after analysis of descriptive and

normative models there is no basis for change, if top

management support is unable to be obtained or if the system

is impossible to build at reasonable cost then it is

probably best to terminate at this point, before investing

large sums of money and time into a doubtful system.

-30-

The main objectives of Step IV are, in summary, to;

1. clearly define the objectives of the system

2. engage the support of top management

3, insure that the system will do what users want

4. insure that the objectives can be met and atreasonable cost

STEP V

Given that a decision is made to continue with the

evolutionary process, the next step is to construct a

plan of action.

ACTIVITY OUTCOME

PLAN COURSE ORDER &OF _ RIORITIES

ACTION OF SYSTEMCOMPONENTS

STEP - V

The proposed system should be broken down into component

parts or modules. A modular approach is more manageable

than one that attempts to bring up an entire system all at

once, In an accounting environment, for example, an MIS for

the controllers department might include the following

modules: general ledger, order entry, accounts payable,

and accounts receivable. Building systems for each module

and then tying them together is a reasonable strategy,

An extension to the modular approach calls for a

hierarchical implementation of modules (17). With this

strategy, the nucleus or most fundamental module is built

first and then components that depend upon it are brought up

-31-

next. In this way the fundamental components of the system

(the kernel) are completed, tested and made operational

before modules that link to them are developed. This

procedure is repeated at the next level and further until

the entire system has been completed. This approach has

been successfully applied to operating systems (46) and

more recently to the development of management information

systems (17, 18, 19, 20).

Other factors may influence the order and size of

system modules. External forces or pressing organizational

needs may cause certain modules to receive higher priority

than others. Such cases must be dealt with carefully.

Planning to deliver a subsystem without its underlying or

supporting modules can lead to frustration and disillusion-

ment of end users.

Another activity in the Design phase is to set up a time

table. Modules are planned for completion according to a

schedule that includes time allocations and deadlines for

documentation, testing, debugging and data collection in

addition to actual programming.

The systems design and time tables should also be

approved by both top management and prospective users, This

represents a promise to deliver a particular service at a

given time and, hence, care should be taken to present a

realistic plan,

-32-

2.3 APPROACH

Two parallel processes follow the MIS design. The

first is to identify hardware/software technology that could

support the system and the second is to breadboard a system

prototype using the most available hardware and software.

These two processes are discussed independantly in the

following sections,

2.3.1 HARDWARE/SOFTWARE CONSIDERATIONS

There is, today, virtually an unlimited menu of

hardware and software technology from which to'choose that

which best suits the needs of the planned system. Unfortun-

ately there is no way to itemize them all and even if there

were it is difficult to compare any more than a few alter-

natives. In some environments there is little or no

flexibility in this selection process. The organization may

be committed to dealing with a particular vendor or to using

already available tin house) technology, The following

technology search is constrained by these factors.

STEP VI

There are many ways to learn about technology alter-

natives that may be applicable to the system.

ACTIVITY OUTCOME

IDENTIFY HARDWARE &EXISTING SOFTWARE

TECHNOLOGY AVAILABLE TOSUPPORT NEWSYSTEM

STEP - VI

-33-

The first source of information is usually simply experience.

Having worked with information systems and exposure through

work or school provides a basicknowledge from which a techno-

logy search can be launched. Finding other organizations

that have implemented similar systems will also be helpful.

Whether other installations have met with success or failure,

analysis of their attempts can give valuable insights. Vendors

are another source of information. Issuance of a Request For

Proposals (RFP) is sure to attract attention and a deluge of

information from commercial enterprises. Technical consultants

can also furnish information, albeit at considerably higher

cost. Finally, texts, journals, conferences, special reports

and industry catologues that document the advantages and dis-

advantages of various technologies are readily available.

The decision to purchase software is, increasingly,

becoming more costly and time consuming than determining

which hardware to employ. This is a by product of an era

which is characterized by rapidly decreasing hardware costs

and continuously increasing complexity and costs of software.

Most management information systems that are appearing in

organizations today utilize a Data Base Management System

(DBMS) (51) as their underpinning. There are a number of

commercially available DBMS packages that vary greatly in

cost, size, and approach. The design team should select a

DBMS that is sufficient to meet the needs of the system

-34-

without incurring -unnecessary overhead. Key dimensions to

consider when purchasing a DBMS are: flexibility, conceptual

view, overhead, performance, security, simplicity and reliability

(13,47).

Some software houses and time sharing services support

several hardware/software configurations. These services can

be used to support the final system or used exclusively as

a testing ground in order to experience alternative systems

first hand (see Section 2.3.2). A management information

system might permanantly operate in a commercial time sharing

environment in order to relieve the organization from having

to maintain its own technology. If this alternative is con-

sidered, factors to be concerned with are: reliability,

security, availability, efficiency, overhead, cost, technical

support, and ability to fine tune machinery or software of

the available systems.

STEPS VII & VIII

After identifying available hardware and software techno-

logies, an evaluation of alternative combinations to determine

that which is best suited to the needs of the proposed system

is undertaken. There is no algorithm to guaranty the selection

of the best components for a given system. Consideration of

cost, capabilities of the components and of the organization

that will use thea, ease of use, flexibility, upward compatibility,

and even intuition all contribute to the final selection.

-35-

ACTIVITY OUTCOME

EVALUATE SELECTIONSTEP VII AVAILABLE CRITERIA

TECHNOLOGY

ARE

YES ANY COM-INATIONS

V IAB

SELECT FROM COMMITMENTSTEP VIII AVAILABLE TO AVAILABLE

TECHNOLOGY TECHOLOGY

A general approach is to establish criteria along relevant

dimensions and to exclude systems that fail to qualify in

every case from further consideration. One from the remain-

ing alternatives is chosen based on the relative importance

of performance along particularly critical dimensions.

There are two caveats to bring up at this time. First,

unless the organization is risk seeking, it is best to select

technology that has a demonstrated ability to do the job.

New or untried technology that will present the organization

with unneeded risk and potential for failure should be avoided.

There have been many instances where substantial investments

have been lost as a consequence of using new and previously

untested equipment.

The second warning concerns the next checkpoint in the

framework. It may turn out that either no technology capable

-36-

of meeting the requirements of the planned system exist or,

if it does, that is too expensive. In this case the objec-

tives of the system may need to me modified, the design

changed, or the technology selection criteria relaxed. The

remaining alternative is to postpone the project until the

technology becomes available, the costs decrease or the

problem changes.

With this step a go/no-go decision is finalized and a

commitment to a specific technology made. The design and

technology are ready to come together in an implementation

effort that commences in the next phase (Section 2.4).

2.3.2 BREADBOARDING OF SYSTEM PROTOTYPE

While the technology search is in progress it is advis-

able to simultaneously implement a small scale prototype of

the system. There are several reasons for pursuing this

strategy. First, a prototype is a relatively inexpensive

means of determining whether or not the final system will be

compatible with what users are expecting to receive. When

completed the prototype is shown to future users to get

an expression of their initial reaction, identify

potential problems with the design, and generate user

interest in the final system. It is far easier to incor-

porate changes demanded from experience with a prototype

than from reaction to the end product. Second the

-37-

prototype allows those who will eventually be responsible for

full scale implementation to go through a learning phase that

will better prepare them for work on the larger version.

Familiarity with data management systems, query languages,

graphic display screens and other "new" technology is acquired

while losing no time and at minimal cost. This kind of learn-

ing and experimentation is much more costly and constrained

if done during "live" implementation. Third, the prototype

will be the foundation for the final system if it is implemented

using the same technology as that which is ultimately selected

for the full scale version.

isSYSTEM

No 0 ON RIGHTRACK

BREAD BOARD SYSTEM TOSYSTENM BE

PROTOTYPE DEMONSTRATED

The technology used for the prototype should be that

which is most available and at the lowest cost, while pro-

viding sufficient capability. In house computer resources,

short term arrangements with a time sharing service, potential

vendors, and university facilities are all possible testing

grounds. Although differences between the prototype and

-38-

actual system will exist (primarily in terms of operational

costs and efficiencies if nothing else), the decision to invest

resources in the final system are based on much better inform-

ation concerning characteristics and benefits of alternative

technologies from having developed a prototype. A prototype

can, then, be effectively employed to significantly reduce

risk, and increase the reliability of a decision to adopt a

particular technology.

The prototype should be tested in the user environment

on a small scale to determine whether or not the design team

and target population are on the right track. The third

checkpoint in the framework is to assess the compatibility

of the approach, as manifested in the completed prototype,

with user expectations. If discrepancies exist they must be

reconciled before continuing with any further development.

If the prototype is consistent with stated objectives but

ellicits an unfavorable response from users then there is

cause for concern. The objectives must be reexamined and

made to more accurately reflect user demands.

The completion of a prototype and a commitment to a

specific technology leads to a transition into the next phase

of evolution, Actualization. It should be reaffirmed here,

that there are two parallel processes that make up the Approach

phase: steps that lead to selection of technology; and steps

to complete a system prototype. There is a good deal of

-39-

interplay between these two processes. Ideally, the

prototype should be brought up using the technology that

is most likely to be chosen for the final system. In

addition, the prototype development should be monitored by

those responsible for selecting the technology so that they

will have as much information as possible upon which to

base their decision.

When choosing modules, subsystems or applications to

be brought up in the prototype environment, care should be

taken to select those that are both easy to do and that will

be sufficiently interesting and demonstrable to users.

Users impressed with the prospective utility and effective-

ness of the final system, because of experience with a

prototype, will have an easier time assimilating the final

version upon its completion.

2.4 ACTUALIZATION

Actualization refers to the programming, documentation,

data collection, installation, testing debugging and finally

use of the system as scheduled during the Design phase.

This is often the most time consuming and aggravatingly tedi-

ous phase of system evolution. It is, however, important that

the routine activities not be treated lightly or that their

role in the evolutionary process be underplayed. Many systems

have had superb designs but were never actualized effectively

-40-

due to lack of resources allocated to the implementation effort.

ACTIVITY OUTCOME

STEP IX

During implementation, Step IX, it is possible to con-

front a situation where a particular design criteria is unable

to be met in a satisfactory manner. In such cases it is

evident that a design change is mandated. For this reason,

the design team should continue its association with the

project through the later stages of evolution.

As modules of the system are completed they are installed,

Step X. Initial, trial useage can begin as soon as enough of

the system has materialized. System modules are often released

ACTIVITY

INSTALLATION

OUTCOME

STEP X

to the user environment before enough of the system has been

completed. The reason systems are released too soon is invariably

IMPLEMENTATION NEW SYSTEM

USEABLE SYSTEM14

-41-

associated with a failure to meet stated time commitments.

If the system is initially planned for release at a particular

time but only a few modules are actually completed at that

point, it is more appropriate to extend the deadline than to

release a portion of the system prematurely. When it is

apparent that a module is going to be late, efforts to expedite

should be set in motion, the implementation schedule revised,

and any problems identified and reconciled. The importance

of well founded time tables set up in the planning step becomes

clear in this phase of evolution. It is better to have been

realistic earlier on, than to require repeated deadline exten-

sions during implementation.

The first users of the system should be carefully selected.

The more progressive users who have displayed an ongoing

interest in the project should be given the first opportunity.

Such users are more likely to have a positive attitude and

thus a higher probability of accepting the system. The impact

of first impressions must also be given serious consideration.

If initial experiences are frustrating and unproductive the

system image will be forever marred.

The degree of operational change directly resulting from

the installation of a new system should be minimized. The

less individuals have to alter their current work habits and

routines, the easier it is for them to accept the system and

to incorporate it as part of their usual activities. Top

-42-

management support, at this stage, is invaluable. If

users are aware of such support, then use of the system is

required to continue in good standing with management.

However, this can be carried to an extreme. If management

insists that the system be assimilated at an unreasonable

rate (change occurs too fast) or if the system is not

functionally useful (due to, perhaps, a poor design) then

even a mandate from the chief executive will result in

defensive, unaccepting behavior by users. Either lack of

top management support or overzealous support can severely

impair the likelihood of success.

These two points, complexity of organizational change

and top management support, combine with extensive user

involvement and a clear statement of purpose to round out

the list of environmental factors that greatly influence

the evolutionary process. Concern for these matters and use

of this framework go hand in hand.

2.5 EVALUATION

Evaluation is perhaps the most difficult phase in the

evolution of an MIS. All too often it is ignored entirely

in favor of yielding to pressures requiring that attention

be given to other matters. Successful evaluation depends on

1) prior definition of system objectives, 2) a means of

monitoring progress towards meeting predefined goals, and 3)

a formal review process when the system is complete (39).

-43-

ACTIVITY OUTCOME

PROPOSALS FORFURTHER REVISIONS

EVALUATION -AND DEVELOPMENT(Return to stepsI-III)

STEP - XI

If the reasons for building the system are not clearly

specified then it is impossible to determine, ex-post,

whether or not the system rates as a success. An advan-

tage to using a modular approach is apparent here. If

every module has a specific purpose then each can be

evaluated individually as they are completed. Success of

the entire system, then, is some function of the success

rate of its modules. (e.g. if 80% of the modules are a

success then the project may, by some standards, be claimed

a success).

Delivery of an MIS is a service rather than a product.

Products can generally be assessed in terms of value as a

net of benefits minus costs or with a rate of return

analysis, as with most capital investments. However, an MIS

rarely results in cost displacement or cash generation.

Thus, there is no ready means of measuring contribution to

the organization in a traditional manner. Justifying the

investment in an MIS is largely an act of faith to begin

with. Rarely is an MIS initiated as the result of a

promise to reap a minimum payoff, (this is one reason why

-44-

it is often difficult to secure top management support for

the system). Support based on cost-benefit ratios is often

misguided, since costs are invariabily underestimated and

benefits intangible (eg. it is difficult to quantify the

value of better information and better decisions).

Success has traditionally been measured by frequency and

length of system use. This, however, has proved an unreliable

indicator. A heavily used system may be cumbersome, ineffec-

tive and superfluous whereas a lightly used system may provide

valuable information at strategic times. Other attributes of

systems have been proposed as success factors by Keen (38).

These include accuracy, timeliness, simplicity, learning, new

needs, new jobs, follow on projects, new problems, new person-

nel, and changes in organizational structure.

Keen and Scott Morton have further elaborated on the

issue of evaluation in their recent book on decision support

systems (39). Much of their material is based on earlier

work done by Keen (38) and is equally relevant to the evalu-

ation of management information systems. Alloway (5)

Carlson (11), and Ginzberg (27) have also made contributions

in this area. One note common to all reports is that a verdict

of success or failure is entirely dependant upon who is per-

forming the evaluation. The designers and builders of a

system are more likely to rate the system a success than are

users or management.

-45-

Use and evaluation of the system are bound to result in

the identification of system failings, a need for new features

and, perhaps, major extensions and revisions. It is difficult

to sort out those changes which fall under the rubric of

system maintenance from those which are simply bug fixing or,

at the other extreme, those that are actually independant

systems. In any case there is a likely need to reexamine

the now existing system to identify new problems, inefficien-

cies and the like. From this phase, then, there is a direct

line to Step II in the overall framework: Analyze the

Existing Environment. The framework can again be used in its

entirety if sufficiently new needs are established.

2.6 SUMMARY OF FRAMEWORK

The proposed framework represents a systematic approach

to the evolution of a management information system. The five

phases of the process include: Needs Assessment, Design,

Approach, Actualization and Evaluation. Each phase is com-

posed of several steps, where each step consists of a set of

activities and outcomes. The outcome of an activity is gen-

erally used as input to the next activity. The eleven steps

are complemented by three checkpoints that are used to deter-

mine whether or not evolution should continue. The Approach

Phase consists of two distinct parallel processes: the

development of a system prototype, and the selection of

technology to support the final system. There is iteration

-46-

between some steps and a liberal "bouncing around" is

encouraged at certain stages.

The framework is developed within the context of four

key concepts that dramatically influence its utility. These

are: there must be a clear statement of system goals and

objectives; there must be substantial user involvement

throughout evolution; top management must actively support

the system; and the degree of organizational change imposed

by the system must be minimal.

-47-

3. CASE STUDY

The guidelines presented in the previous section are

now applied to an actual case study in order to demonstrate

their utility in a particular setting. The organization

used in this example is the Pennsylvania State Department

of Education. An organization chart of the department

is found in Appendix A. The Bureau of Information Systems

is the focal point of discussion. An organization chart

for the Bureau is found in Appendix B.

3.1 NEEDS ASSESSMENT

Four days of on site visits by two analysts were

used to conduct the Needs Assessment phase. Formal inter-

views, informal discussions and group meetings were con-

ducted at all levels of the organization to get an inside

view of the existing environment.

Description of Existing Environment (Step I):

The Bureau of Information Systems is a service center

and receives ad-hoc requests for information, reports,

and analyses in addition to being responsible for com-

piling and distributing standard, institutional reports

to other branches of the department on a regular basis.

The Bureau's Division of Computer Services (see Appendix B)

maintains over one hundred and fifty computer programs

(written predominantly in COBOL) that are aggregated

into 70 applications. Example applications include:

-48-

Annual Financial Accounting, School Attendance, Trans-

portation, and Federal Registrar Reports. The application

studied here bears the rubric "Act-580" and is one of

seventeen subsidies used to distribute state funds to local

school districts. The application is of interest because

of the problems associated with its use and because it is

an example of an application that may benefit from infor-

mation systems support.

The School Subsidy Program (Act-580) has been in use

since 1965. At that time a formula was constructed to

calculate the amount of dollars to be distributed among

the 505 school districts throughout the state (the actual

number of districts has fluctuated over time and currently

stands at 505). Act-580 is the largest of the seventeen

subsidies, accounting for over 80% of all subsidy funds

distributed to school districts throughout the state.

The total dollars allocated through the subsidy currently

sum to nearly $1.25 Billion.

Act-580 has three main goals. First; a prediction

of total school subsidy disbursements is required by the

Governor's Budget Office on an annual basis. The budget

figure represents an amount of money expected to be dis-

tributed to school districts at the end of the fiscal year.

A prediction for the coming fiscal year is, ideally,

available on July first. In order to plan ahead, the

Budget Office requires that a prediction for two years

-49-

hence be provided and that this be updated with a second

estimate after a year has passed. Estimates a-re provided

by the Division of Educational Statistics (see Appendix B)

and are based on the current school subsidy formula.

Estimates have tended to be within .2% - .5% of actual

subsidy amounts.

The second goal of the subsidy system is to assist

local school district planners by providing them with an

indication of the state dollars they can expect to receive

for instructional expenditures.

The third goal is to provide a means of "testing"

alternative subsidy formulas in order to establish more

"equitable" means of distributing funds. Periodically

(roughly every three years) the formula undergoes extensive

analysis and revision. Reworking consists of generating

alternative formulas, determining what the distribution of

funds would be with the new formulas, analyzing the results,

presenting results to others for discussion and, often,

generating still other formulas. When a formula that meets

with the approval of the legislative body is established,

it becomes the new mechanism for determining subsidy awards.

This process continues from January to July or until a

suitable formula is found. The process can continue into

November if no consensus is reached until then. Several

hundred formulas are tested over the course of the six to

-50-

nine months. In the current year (1977), nearly 100

formulas have been tested from mid-January to mid-April.

Up to six formulas are under study at one time and on the

average two to three are "in process". Proposed formulas

are generated by the legislative General Assembly, the

Budget Office, the Governor, the Teachers Union and the

public. When a formula has been submitted for testing to

the Statistics Division, the proposal originator would like

to learn its bottom line and distributional impact imme-

diately, but typically must wait for one to three days

while a computer program to "test"the formula is written

and run. Results of a test run are returned to the statis-

tics office and from there are passed on to the proposal

originator. When presented to other parties for discussion

the results generally lead to political debate and, often,

another proposal to be tested. An illustration of this

process is shown in figure 5.

It is this goal that serves as the focal point of

this case study. The current subsidy formula is detailed

in Appendix C. Basically it consists of four components;

a base subsidy, a density factor, a sparsity factor and a

poverty factor. There are currently ten separate data

series used to compute the amount of subsidy. Proposed

changes to the formula include raising and lowering constants

and multipliers, restructuring conditional allotments, and

altering the actual mathematics. Several new data series

-51-

Figure 5Current Subsidy System

STATISTICIAN

DATA PROCESSINGPERSONNEL

PROGRAMTO

TESTPROPOSEDFORMULA

-52-

have been proposed as additional components and it has been

suggested that some data series be dropped or extensively

modified, (see examples of proposed formulas in Appendix D).

Previous reworking of the formula has resulted in

several ammendments that attempt to correct inequities.

For example, the addition of a density factor required

subsequent inclusion of modified density, super density,

and modified super density when it was realized that density

levels change over time and that some school districts have

excessively large density levels. Qualifiers and guarantees

are also common. Currently, there is a written guaranty

that no district shall receive a subsidy less than that

received in 1972.

The decision to adopt a new formula is entirely poli-

tical in nature. Legislators support a proposed formula

only if a test run shows that their districts are treated fairly

relative to others. In general, a large number of proposals

must be considered before consensus is reached. Special

interest groups also play an important role, as they apply

pressure to the members of the General Assembly. The

Teachers Union is a notable example of a group currently

exerting such influence. Teachers are prepared to strike if

an unacceptable subsidy formula is adopted.

Analysis of Existing Environment (Step II):

Having become familiar with the existing environment,

-53-

through the development of a descriptive model in the

previous step, it is discussed with representatives of the

Department, and is analyzed to uncover problems, inefficien-

cies and bottlenecks. Identified issues are presented below

in order of importance as perceived by the analysts, the user

responsible for mediating between submitters of proposed

formulas and the computer personnel, the data processing

staff, the assistant director and the director of the Bureau

of Information Systems.

The lack of continuity in formula generation, analysis

and regeneration is the most severe constraint in formula

development. The submitter of a proposal must wait up to

several days for the results of a test run. This time lag

requires the proposal originator to refrain from selling his

ideas to others until test results are available. Valuable

time is lost in this delay and there is a corresponding loss

in momentum from a policy making perspective. Associated

with this issue is a tendency to confuse alternative for-

mulas. It is difficult to keep track of proposed formulas

when there are any more than a few for which test run results

are unavailable. The time to generate, test run, analyze,

present, discuss and modify a proposal requires at least a

week. Those involved have expressed much concern for this

bottleneck and have identified an urgent need to expedite

the process.

-54-

A ramification of the excessive amount of time to

process a single proposed formula is manifested in terms

of the total time it takes to reach a final decision to

adopt a new formula. Ideally the estimated subsidy amount

should become part of the Governor's budget by the first

of July. However, the final formula may not even have been

agreed upon until as late as November, causing problems for

even the highest level of authority.

In a parallel with the time to process dilemma is an

issue of completeness. Fine tuning of proposed formulas

is time consuming and, hence, generally is not done. Thus,

a great many variations on a theme remain unexplored.

Similarly, proposals that would take a great deal of effort

to test are never even proposed. The number of proposals

considered, then, is limited.

Currently, the data processing center budgets close to

one full man year of effort to accomodate the computational

requirements of Act-580. Included in this time is, re-

programming needed to generate test runs, acquiring and

often rekeypunching data needed by a given formula (even

if the data is used for another application it must generally

be reformatted or resorted to run under Act-580), and

actually running the new formulas (this is usually done at

night since day time computer resources are running at full

capacity).

-55-

The burden upon the data processing staff due to Act-580

is substantial and ever growing as formulas tehd to only

increase in number and complexity.

The data processing staff also find themselves facing

confusion and frustration when a large number of alterna-

tives are "in process" simultaneously. According to one

statistician, it recently took a one half hour conversation

with a programmer to identify which proposed formula the

statistician had.called to discuss.

The director of statistics often find this response

time to be inadequate. Rather than wait for a proposal to

be processed by the computer center, he will take an entire

day and a handful of staff to work through a proposed

formula manually.

Finally, the current mode of operations can lead to

costly mistakes. Typically, a formula will be tested

using a modified version of the current subsidy program.

The danger is that the wrong version of the program will

be discarded after testing. This actually happened recently

and lead to inaccurate final estimates being submitted to

the budget office.

The list of problems in prioritized order are summarized

below:

-56-

Summary of Problems with Present State Computational Systemto Handle Act-580

1. lack of continuity and momentum in formula generation

and analysis

2. proposed formulas take too long to process (one to three

days)

3. total time needed to select a new formula is too long

(six to nine months)

4. not enough proposals are considered (100-200)

5. it is difficult to fine tune proposals

6. it takes a full man year of DP support to handle Act-580

7. it is complicated and confusing to multi-process several

proposals

8. new components to the formula require extensive time

to collect and process data that may or may not already

be used by other application

9. there is a lack of available computer resources

10. manual processing is tedious and time consuming

11. formula testing can lead to mistakes and erroneous

data used for policy making

12. it is difficult to know whether or not a given formula

has already been tested

-57-

Before developing the specifications of a subsidy

system in which the noted problems are resolved (i.e.

construct a normative model), consider the application in

terms of the two mechanisms presented in Section 2.1.

Analysis of the problem area with respect to the Gorry-Scott

Morton framework for decision making and then in terms of

the Keen-Scott Morton table of information characteristics,

gives an insight into the system's generic nature. The

selection of a formula to determine subsidy allotments is

clearly not a structured task (refer to figure 3). There is

nc way to impose a straight forward algorithm or linear

program to insure that an optimum formula is selected.

Neither is it a totally unstructured process, as there are

implicit heuristics and rules that govern the final selection.

For example, no district can receive less than it did last

year, and if a particular form of aid is received once

(e.g. sparsity aid) then it shall always be received. Semi-

structured, then, appears to be the appropriate classifica-

tion. The decision category lies somewhere in the range

between strategic planning and management control. This

combination (semi-structured/management control) places

the system in a class that has had only little history of

successful information systems support (39). In some ways,

though, this example is remarkably similar to the Westing-

house case discussed by Scott Morton (55), particularly

-58-

with respect to the issues of: time to select an alternative,

the number of alternatives to consider, and the thoroughness

of formula testing. The information system developed in that

case provides valuable lessons for this system, but will be

left for the interested reader to explore in detail.

Analysis of data used in Act-580, along the dimensions

presented by Keen and Scott Morton (39) reveals that the

various data series used in this application span over a

considerable range. In fact, it is clear that the current

system uses data of inconsistent quality, accuracy, and

age (see Appendix C). Focusing upon the goals of the

subsidy program, a general picture of information charac-

teristics can be formulated as seen below:

-59-

Act 580 Information Characteristics

DataCharacteristics

Accuracy

Level of Detail

Age

Source

Scope

Type

Ballpark figures are sufficient for

budget estimates

School District and State Wide-no need

to be too detailed (i.e. school level)

Past data is used when present data is

unavailable; present data is used

instead of estimating future figures

Internal

Wide

Quantitative

Time Horizon Future

-60-

Description of More Desireable Environment (Step III):

The director of the Information Systems Bureau and

both the head statistician and the data processing manager

expressed their perception of an ideal Subsidy System in

terms of an interactive facility. This facility would

enable easy entry of new formulas and provide estimates of

total dollar and distributional impact. The focal point of

such a system would be a station for incoming proposals to

be entered (e.g. via display screen or computer terminal),

run immediately, and results returned instantaneously.

Incoming proposals would be assigned an identification code

to keep track of who made the request and to maintain a

history of proposals. It is unlikely that members of the

general assembly would benefit from direct access to the

system. Rather, it is more appropriate to assign an in-

dividual (in the Statistics Division) the responsibility to

run proposals from a central sight as they come in by phone,

in person or by memorandum.

Information available for formula testing should include

any data kept at the district level. A district data base

would be maintained by the data processing staff for this

purpose. If a proposed formula includes district data used

by some other application it should be available through

the district data base. New data should be added as needed

to increase the alternatives open to formula generation.

-61-

Information available for formula testing should

include any data kept at the district level. A district

data base would be maintained by the data processing staff

for this purpose. If a proposed formula includes district

data used by some other application it should be available

through the district data base. New data should be added

as needed to increase the alternatives open to formula

generation.

Results of test runs should also be available in hard

copy form for distribution to interested parties. Such

printouts can come from either a screen copier or from a

line printer.

This systen, once implemented, would require only

minor reprogramming and maintenance efforts by the data

processing staff from year to year. Their primary respon-

sibility would be to provide an accessible reliable and

integrated base of data around which the Subsidy System will

function.

3.2 DESIGN

Analysis of Normative Model and Viability of SystemGoals (Step IV and Checkpoint I)

The goals-of the proposed system as derived from an

analysis of the descriptive model are:

- to provide continuity and momentum to the searchprocess

- to allow more proposals to be considered

-62-

- to allow fine tuning of formulas

- to provide immediate and unambiguous feedback fromtest runs

- to provide a means of viewing results by schooldistrict, legislative district or in aggregateby county and state

- to keep track of proposals and who has generatedthem

- to easily incorporate new variables into the formula

- to allow components to be dropped from the formula

- to substantially reduce the clerical workload intesting formulas

- to substantially reduce the need for continuous dataprocessing support

- to ultimately arrive at more equitable subsidydistributions

Given the demonstrated success of similar systems (18,

21,27, 55), these objectives appear to be both reasonable

and viable. Readily available technology shoudl be suffi-

cient to attain them.

Support for these design objectives was easily secured.

The director of information systems, the head statistician,

and data processing personnel all displayed keen interest

and enthusiasm for the proposed system. A commitment to

provide resources and personnel- support during systems

development and implementation was made by top management.

System Components and Plan of Action (Step V):

The following activities should be performed to

establish a complete system and in the the time frame shown,

-63-

relative to the start of system development:

- stabilize district database (weeks 1-8)

- develop or acquire software environment from whichformulas can be tested and results displayed(weeks 3-15)

- establish human interface to the system (weeks 12-20)

- resolve procedural and logistic details (weeks 18-22)

- establish procedures and capabilities to maintaindistrict database (weeks 18-24)

- provide a means of tracking and storing proposedformulas (weeks 12-20)

- document supporting software and operating procedures

- evaluate system modules (as completed)

The nucleus of the system is an integrated database of

all information maintained at the district level. The

ability to access and manipulate this data gives the flexi-

bility needed to test and track alternative formulas. An

illustration of the proposed system is shown in figure 6.

The system modules were recognized and approved by the

Bureau of Information Systems. The time tables and scheduled

dates for completion are currently under consideration.

Approval of a final schedule is expected soon.

3.3 APPROACH

Identify and Evaluate Available Technology (Steps VIand VII)

The Bureau of Information Systems, despite its heavy

-64-

Figure 6Proposed School Subsidy Information System

T/O VIA KEY-BOARD OR DIS

CIAN

ResultsProp-osals

-65-

use of computer resources, does not currently own and

operate its own equipment. Due to increasingly computa-

tional requirements and an increasing desire to control

accessibility, activity and operations, the Bureau has

requisitioned and received approval for funds to acquire

its own computer facility. A request for proposals has

been issued and a decision to purchase a medium sized

computer is emminent. The hardware must be capable of

supporting a commercial data management system and be

able to operate in both a batch and interactive mode. In

the opinion of the analysts, at least two vendors, IBM and

UNIVAC, are capable of supplying the required resources.

The chosen facility will most probably be in the range of

IBM 370/138. A DBMS that uses a hierarchical conceptual

view of data is preferred by the user environment due to the

relationships that exist between county units, counties and

school districts. These relationships are of more relevance

in other applications than in the case of the School Subsidy

system. ADABASE, SYSTEM 2000, and TOTAL are all being

considered for this- role, (see (51) for a description of the

various DBMSs).

Checkpoint II and Selection from Available TechnologyStep VIII)

It appears that sufficient hardware and software re-

sources are available to meet the system objectives detailed

-66-

in the Design Phase. The underlying selection criteria are

currently being developed in conjunction with the user

environment. Final selection of hardware and software tech-

nology will be made in due course.

Breadborad System Prototype:

In order to test the viability of the Act-580 design

presented above, and to become better acquainted with the

computational requirements of the system, a prototype was

developed. The prototype will be shown to users and tested

with actual proposed formulas to determine whether or not

the system will be useful when complete.

A partial view of the complete District Database under-

lying the prototype is shown in figure 7. Essentially,

there are a set of attributes (columns) associated with each

of the 505 school districts (rows). Janus, an experimental

host language supported by MULTICS, is used to provide access

to the data from an interactive computer terminal.

The prototype uses a relational schema (13) on hardware

that is unlikely to be chosen for the final system. The

relational approach is well suited to the needs of this

system but is generally unavailable in the form of a

commercial product. It is used here as it is a convenient

vehicle for the purposes of demonstration and because it was

readily available and at low cost. It is expected that the

capabiliteis shown here can be transferred to the hierarchi-

-67-

cal schema supported by the DBMS ultimately chosen to

underlie the final system. The hardware (Honeywell 6180)

is employed for similar reasons; it was readily available

and at lost cost, while it provides ample computational

capability.

display mktval,incomeafdcpovertyaie,pop_per areawadm sort on cnty,distnamewith title="Figure 7"/District Database"/(Partial Listing)",blocking,1n1=95 for 1 to 20

Figure 7District Database(Partial Listing)

afdc povertywadm

aie popper-area

BERMUDIAN SPRINGS SDCONIEWAGO VALLEY SDFAIRFIELD AREA SD

00 GETTYSBURG AREA SDLITTLESTOWN AREA SD

UPPER ADAMS SDALLEGHENY VALLEY S DAVONWORTH UNION S DBABCOCK S DBALDWIN WdHITEHALL S D

BETHEL PARK S DBRENTWOOD BORO S DCARLYNTON S DCHARTIERS VALLEY S DCHURCHILL AREA S D

CLAIRTON CITY S DCORNELL SDDEER LAKES SDDUQUESNE CITY S DEAST ALLEGHENY S D

39539100846525004080340014283330047609500

46331800979708005252560087217500

261263700

2458523006952190092123200

210492600202320500

998656008790330062813900-67410400123556200

2383235756461739111069137096898130087391

266846535395446845563402561499804

208852198

1838114665226608379830529

150528372136422434

4208247934362599482994133340773973860528

distname mktval I ncome

84369

23241

40

68129

6862

236

92103277206

88

592232127482315

198294167424

89

2452521541,76525

272235I431379184

1071385300812604

14753302371957

89354041210571941263

1642350330591723844183472124

10699690

109590782180118353984672340616701731

31467142228624371678820639574434449

79215

54101162

771433

922380

4803

29909809579620823584

50173484

34260052156

18293269100144232362

19772822213633729950

106432221341167255690

23061632362518324095

-69-

Abbreviation

distname

-mktval

income

c:fdc

poverty

Ale

pop-per-area

Meaning (reference Appendix C)

the school district name

the market value of the district'sreal-estate

total income earned by wage earnersin the district

number of pupils receiving aid tofamilies with dependent children

the number of poverty pupils in thedistrict

last year's actual instructionalexpenses

the population per square mile

weighted daily average membership

(Figure 7 continued)Explanation of column Headings

-70-

The data shown in figure 7 is operated on according

to the rules of the current formula (Appendix C) to arrive

at the subsidy payments shown in figure 8. Figure 9 shows

a partial frequency distribution of subsidy allotments

by district. The vast majority of districts receive

between .04% and .21% of the total subsidy disbursements.

Philadelphia and Pittsburgh receive 2.63 and 16.94 percent

of the total subsidy respectively but are not shown in the

figure.

The subsidy components (base, density, sparsity and

poverty) are calculated using the formulas detailed in

Appendix C and as shown in the listing of macros in

figure 10. The macros are employed by the user in place

of typing in the formula each time an estimate is desired.

To calculate the density subsidy, for example, the user

types "create-density(density)". To arrive at a total

subsidy for a district the user sums four component parts

to the formula. The calculations are performed as shown

in figure 11 along with the calculation of total subsidy

payments, (computer responses are indented).

To test a new formula the user may change the macro

definitions shown in figure 10 and re-execute them. An

example of this procedure is shown in figure 12 where the

following changes are made to the current formula:

-71-

1. base subsidy maximum per WADM expenditure changed

to $900 from $750

2. district income, instead of market value used to

calculate the aid ratio

3. and the poverty multiplier is increased to $200

from $165

The results of this formula are shown in figures 13 and 14.

display cnty,ar nmfd=3,current_base,densitysparsity,poverty_dollarssub sort on cnty,distnamebreak on cnty tally currentbasedensitysparsity,poverty_dollarssubwith title="Figure 8"/Subsidy Components"/By County and District'/(Partial Listing)",1nl-95for cnty-1 I cnty-3 I cnty-7

Figure 8Subsidy Components

By County and District(Partial Listing)

cnty ar currentbasepoverty-dollars

density sparsity

BERMUDIAN SPRINGS SDCONEWAGO VALLEY SDFAIRFIELD AREA SDGETTYSBURG AREA SDLITTLESTOWN AREA SDUPPER ADAMS SD

APOLLO-RIDGE SDARMSTRONG S DFREEPORT AREA SDLEECHBURG AREA SD

ALTOONA AREA SCH DISTBELLWOOD ANTIS S DCLAYSBIJRG KIMMEL S DHOLLIDAYSBURG AREA S DSPRING COVE S DTYRONE AREA S DWILLIAMSBG COMMUNITY S

0.5910.5100.2290.3890.6190.557

0.7810.7160.6760.610

0.6280.6740.6480.5890.6820.7180.731

8114471210756

17217112917711096432

826106

5408683

171327068032141433401809256

10759141

67407611108253

611839263325517010541790207503904

15089273

21378968

507434959212120

24002

788123358

9317110861

51616

21660345231652

1685366914834

907

252063

1136030

5279900

126670

293071

326704851027555699601468540425

233805

0 968550 3664650 374550 273065

0 528165

00

7750000

22G760154530

458790

444510381154504591410631957359024420

780285

distname sub

9598561268234253032

13660801117038

995321

5959561

181800671930371480173

11338922

74018741150892736036

274151817709402095390683761

16580410

0

000ouo00

Uouo-00,0

00000000000,0

000600000

COU0000000

000000

0000OU0

000000OUD

ooooouuouo

oooouuouuuooo

oooooouuouo

c

00600000000000

0uoooooooooooooooouu

ooooouooooouuooo

uuouoooooooouuuu

oocouuuooouoooouuoouoouoououoooooo.

00000000000000000000000000

0000000000000OU00OU00oooooo

c6ouGuuuuooGououoouuu0000000G00

oooououuuooooooooouoooooooooo

Ln

oooooooouoooouooooooooouooouoooooooooouooI

oououoouuoouuoooooooo000000000000000

VI

00000000000000000000OU00000000

oouoooooooooooouooo-o

00000000OU0000

Ln

OU006000000000

00

0

0000000

coo0

L 'I.

9

tv

0 17

L06s zL

z9 zs -

ztz

_E

-z

z zI zOIZ-G

i21L

1-91STk

i-

Z-1

1-1-01-

0

W C-

:3- U,

:3 1---- 4--

w

-4-- Q

,

U:*

C-

C-

:3-il

C-

il

NI

uc-

-EL-

display-attribute Name,Definition in Macrodefinitions with ttl="Macros", lnl=89;

Macros

Name

createaid_ratio

createbase

createsparsity

Def i nit ion

*

'createattribute arg1 as1-((mktval/wadm)/(totmktval/totwadm))*0.5;change_attribute arglfor argl<0.1:0.1' with parameters argI

'createattribute argI as(aie/wadm)*ar*wadm for aie/wadm>750,otherwise 750*ar*wadm' with parameters arg1

'createattribute arg1 as(2-pop-per-area/50)*250*ar*wadm forpopper_area(100&popper_area>50, 250.*ar*wadm forpopper_area(=50, otherwise 0' with parameters arg1

'create_attribute TEMP as ar f.375;create_attribute argI aspop-perarea>10000&wadm<50000,wadm>50000&pop.perm.a rea>10000,wadm>50000&popper_area<10000,for pop-perarea(10000&wadm<50missing;delete_attribute TEMP'

or ar>.375, otherwise250. *TEMP*wadm for0.19*ale for(pop.permarea*0.19*aie)/10000. forwadm*(popper_area/10000)*250.*TEMP

000, otherwisewith parameters arg1

createpoverty 'createattribute argl as 165*poverty' with parameters argl

Figure 10Macros Used to Compute Subsidies

create_density

create aid ratio(ar)

createbase(current_base)

createdensity(density)

create-sparsity(sparsity)

create-poverty(poverty-dollars)

createattribute

create_a ttr ibute

sub as currentbase+density+sparsity+poverty-dollars

9,t a1syb s i, diy

dsa total_sybsidy

total,_subsidy

1537040160

Figure 11Commands to Calculate

AllotmentsSubsidy

a's. s tam,(svu )

display Name, Definitionvertical _attrspacingl=1

in Macrodefinitions with title="New Macros", 1n1=90,sort on Name for locatetext(Name,"_2")'=O

New M4acros

Name Defi ni tion

createaidratio_2 'create attribute argI1-((income/wadm)/(totifor argl<0.1:0.1' with

asncome/totwadm))*0.5;change_attribute arr1parameters arg1

create_base_2

create_density_2

create_poverty_2

createsparsity_2

'createattribute arg1 as(aie/wadm)*ar2*wadm for aie/wadm>900,otherwise 900*ar2*wadm' with parameters arg1

'create attribute TEMP as ar2 for ar2>.375, otherwise.375;createattribute arg1 as 250.*TEMP*wadm forpopper_area>10000&wadm<50000, 0.19*aie forwadm>50000&popperarea>10000, popperarea*0.19*aie/10000 forwadm>50000&popperarea(10000, wadmn*(popper_area/10000)*250.*TEMPfor pop~perarea<10000&wadm<50000, otherwisemissIng;delete_attrebute TEMP' wi th parrnotorr nrsl

'createattribute arg1 as 200*poverty' with parameters arerl

'createattribute arg1 as(2-popper_area/50)*250*ar2*wadm foirpopperarea<100&popperarea>50, 250.*ar2*wadm forpopperarea<=50, otherwise 0' with parameters arg1.

Figure 12Macros used to Compute Subsidies

(Alternative Formula)

display cnty,current_base_2,density2,sparsity2,poverty_dollars2,sub2 sort on cnty,distnamebreak on cnty tally currentbase_2,density2,sparsity2,poverty_dollars2,sub2with tItle="Figure 13"/Subsidy Components"/By County and District"/(Partial Listing)",1n1=95for cnty=l I cnty-3 I cnty=7

Firure 13Subsidy Components

By County and District(Partial Listing)

distname

BERMUDIAN SPRINGS SDCONEWAGO VALLEY SDFAIRFIELD AREA SDGETTYSBURG AREA SDLITTLESTOWN AREA SDUPPER ADAMS SD

APOLLO-RIDGE SDARMSTRONG S DFREEPORT AREA SDLEECHBURG AREA SD

ALTOONA AREA SCH DIST 7BELLWOOD ANTIS S D 7CLAYSBURG KIMMEL S D 7HOLLIDAYSBURG AREA S D 7SPRING COVE S D 7TYRONE AREA S D 7WILLIAMSBG COMMUNITY S 7

densIty2cnty current_base_2

10152541446609606798

21755G413289171072870

7646013

1674179725300115996201011562

11538361

71994591381324766890

294998519739262042333613395

16927310

22288639

910589659802295

25949

641820091

866510028

45201

19278546811726

1573364704595

858

226849

poverty_dollars2sparsity2

1134460

15507100

137089

410606

0000

0

00

8094900

215580146222

442751

396005880033400848001780049000

283400

117400444200

4540033200

640200

5338001620054600

1108007660089200296(00

945800

sub2

11755281514049796179

226626013526971261254

8365968

1797997771729116536841054790

12223762

79310441432205904165

307651820569962351707

790076

18542711

00 I

01

000

|01

000 I

00 I

000 I

00000 I

01

000000000000

I

000 I

01

'000 I

000 I

00 I

00000 I

000000

I00000

I

000000000

I0000000000000

I00000000

I000000000000000

0000000000000

I0000000000000000

II00000000000000

000000000000000000000I

ooouooouooouoooo000000000000000000000

IOUOOOOOOOOOOOOOOOOOOOOO

Iooo

00000000O0000000000000LO00000000U0U0000000

IU0000000000000000000000000000

0000000000000"000000000000

0000000U00000000

000000000

U0001

-8L-

6tz

Li

9 1

61

LI91it

LIII

01

68L99I0

Cu

0

-3o.14

0 /

:H

-H 4.x

N0E

-40-.04Q

-79-

The Act-580 system has evolved through the Needs Assess-

ment, Design and most of the Approach phases. Evaluation

of technology and review of the system prototype are

2urrently underway within the user environment. Commitment

to -a specific technology and to an approach will be estab-

1-ished -in the near future.

-3.4 Summary of Case Study

Trhis ?-ase study demonstrates that the guidelines pre-

Eanted in Section 2 can be effectively employed. This is

&ne within the context of the key environmental factors

-that -influence systems success. In the Needs Assessment

.phase an understanding of the existing environment was

rformulated. This was used to establish a clear statement

-of the proposed system's objectives in the Design phase.

4sers -actively participate in the construction of a des-

criptive model and design of a normative model to insure

hait ~the final system will be accepted and productive when

Conplete. Top management support is manifested by the

7promise to supply ongoing personnel and resource assistance

cthroughout system development. The proposed system has been

-kpt simple and uncomplicated to facilitate its assimila-

tiLon by-the organization during implementation.

-The -feature that distinguishes this framework from

76thers is its use of a system prototype. The one developed

in the case study conveys that a prototype, as an active

-80-

model, illustrates the capabilities of the future system.

This enables the analyst to determine the need.for any re-

finements to the system's design. In addition, the proto-

type may generate user interest and enthusiasm for the

final product.

This framework, through the incorporation of a system

prototype, enhances the process of MIS evolution. The

example presented in the case study is evidence of its

utili-ty Lin a particular application. It is expected that

future usage will reveal its utility in other applications.

-81-

BtBLIOGRAPHY

1. Ackoff, R. L. and Sencupta, S.S. "Systems Theory", JEETransactions on Systems Science and Cybernetics,Vol. I, November, 1965.

2. . "Management Misinformation Systems",Management Science, December, 1967.

3. Alter, Steven. "Computer Aided Decision Making inOrganizations: A DSS Typology", Sloan SchoolWorking Paper 855-76, May 1976.

4. Anthony, R.N. Planning and Control Systems: A Frame-work for Analysis. Boston, Harvard University

.Graduate School of Business Administration, 1965.

5. Alloway, Robert. "Temporary Management Systems Appli-cation of a Cantingency Model to the Creation ofComputer Based Information Systems",Ph.D. Disser-tation, MIT Sloan School of Management, August,1976.

6. Argyris. "Management Information Systems: The Challengeto Rationality and Emotionality", Management Scinece,vol. 17, no. 6, February, 1976.

7. Barnette, Joseph. "How to Install a Management Informa-tion and Control System", Systems and ProceduresJournal, September-October, 1966.

8. Blumenthal, Sherman. Management Information Systems:A Framework for Planning and Development. PrenticeBall, 1968.

9. Brady, Ronald et. al. ADP, The Case for ExecutiveManagement Involvement. National Center forHigher Education Management Systems at WesternState Commission for Higher Education, 1976.

10. Burstaller and Forsyth. "Key Result Approach toDesighing Management Information Systems",Management Advisor, May-June, 1973.

11. Carlson, Eric. "Evaluating Impact of Information Systems",Management Informatics, vol. 3, no. 2, 1974.

-82-

12. Chorafas, Dimitris. Control Systems Functions andProgramming. Academic Press, 1966.

13. Date, C.J. An Introduction to Database Systems.Addison Wesley, Reading Mass, 1975.

14. Davis, Gordon. Management Information Systems: Concep-tual Foundations, Structure and Development.McGraw Hill, 1971.

15. Deardon, John. "MIS is a Mirage", Harvard Business Review,January-February, 1972.

16. DiFranco, Steven. "use of Hierarchical Decompositionin Computer Systems Design", Masters Thesis, MITSloan School of Management, June 1977.

17. Donovan, John J. and Jacoby, J. "Hierarchical Approachto Information Systems Design", Sloan School workingpaper no. 762-75, January, 1975.

18. . "Experimental Systems for

Data Management and Analysis", MIT Energy Lab workingpaper no. MIT-EL-75-Oll, September, 1975.

19. . "VM Communication for the Implemen-

tation of Decision Support Systems", MIT Sloan Schoolworking paper. no. 884-76, December, 1976.

20. . "Database System Approach to Manage-

ment Decision Support", Transactions on Data Systems,vol. 1. no. 4, ACM Journal Publication, Fall 1976.

21. and Madnick S.E. "Institutional andAd-hoc Decision Support Systems", to appear in:Data Base, vol. 8, no. 3, Winter 1977.

22. Ellis, David 0, and Ludwig, Fred, J. Systems PhilosophyPrentice-Hall, 1962.

23. Feignbaum, Donald S. "The Engineering and Management ofan Effective System", Management Science, August 1968.

24. Fisher, D.L. "Management Controlled Information Systems",Datamation, June 1969.

25. Gibson, Cyrus F. and Nolan, Richard L. "Managing FourStages of EDP Growth", Harvard Business Review, 1974.

-83-

26. Glans, Thomas, et. al. Management Systems. Holt Rinehartand Winston, 1968.

27. Ginzberg, Michael. "Implementation as a Process ofChange", MIT Sloan School working paper no. 797-75,July, 1975.

:28. Gorry, A. and Scott Morton, M.S. "A Framework for Manage--ment Information Systems, Sloan Management Review,FAll, ~1971

29.. Grace, B.F. "Training Users of a Decision Support System",IB M-Research Paper, San Jose California, May 1976.

30. . "A Case Study of Man/Computer ProblemSolving", IBM Research Paper, San Jose California,erekryary, 1976.

31. Hanold, Terry. "Executive View of MIS", DatamationNovember, 1977.

32. Heny, D. F. Development of Information Systems.Ronald Press, 1968.

33.. Ho, Yin F.F. "An Analysis of the Characteristics andNeeds of the End Users of Data Processing Services",'MIT Sloan School of Management, Masters thesis,June, 1977.

34.. Hopeman, R.I. Systems Analysis and Operations Manage-ment. Merrill, 1969.

35.. Hopkins, R.C. "A Systematic Procedure for SystemsDevelopment", IRE TRANS in Engineering Management,J=ne 1961.

36. Jain, Suresh. "Simulation Based Scheduling and Manage-ment Information Systems", Interfaces, vol. 6, no.1,November, 1975.

37. :Kast, F.E. "A Dynamic Planning Model", Business HorizonsJune, 1968.

38. Keen, Peter. "Computer Based Decision Aids: Evaluation",Sloan Management Review, Spring, 1975.

39, and Scott Morton, M.S. DSS: An Organ-izational~Perspective. Draft of Text, January 1977.

40. Kennevan, Walter, J. "MIS Universe", Data Management,September, 1970.

-84-

41. Kolb, D.A. and Froham, A.L. "An Organizational Develop-ment Approach to Consulting", Sloan ManagementReview, Fall, 1970.

42. Lewin, K. "Frontiers in Group Dynamics", Human Relations,January, 1943.

43. Lincoln, T.J. "Impact of Changing Business Environmenton Management and their Information Needs", Manage-ment Datamatics, 1976.

44. Little, John, D.C. "Brandaid: A Marketing-Mix Model",Operations Research. vol. 23, no. 4, Summer 1975.

45. Lucas, Henry. Toward Creative Systems Design. ColumbiaUniversity Press, New York, 1974.

46. Madnick, S.E. and Donovan, J.J. Operating Systems.McGraw Hill, New York, 1974.

47. Martin, James. Computer Data Base Organization.Prentice Hall, New Jersey, 1975.

48. Minami. "Management Issues in the Data Base Plan",Auerbach Journal, 1976.

49. Morgan, Howard and Soden. "Understanding MIS Failures",unpublished text of of oral presentation.

50. Optner, S.L. Systems Analysis for Business Management.Prentice Hall, 1960.

51. Palmer, Ian. Data Base Systems: A Practical Reference:QUE Information Sciences,Wellesley Mass, 1975.

52. Rockart, J. "model Based Systems Analysis", IndustrialManagement Review, Winter, 1970.

53. Runkle and Windecker, "United Auto Cases A,B, & C",MIT Sloan School of Management, 1976.

54. Silzer, J.M. "Evolutionary Design of Complex Systems",Systems: Research and Design, Wiley, 1961

55. Scott Morton, M.S. Management Decision Systems. HarvardUniversity Graduate School of Business Administration,1971.

56. Sippis, Charles. Data Communications Dictionary. VanNostrand Reinhold, New York, 1976.

-85-

57. Simon, H.A. The New Science of Management Decision.New York, Harper & Row, 1960.

58. Sterling, Theodore, "Guidelines for Humanizing Com-puterized Information Systems", Communications ofof the ACM, vol. 17, no. 11, 1974.

59. Swanson, E.B. "Information Systems Approaches", Manage-ment Datamatics, 1976.

60. Thome, P.G., and R.G. Willard, "The Systems Approach:A Unified Concept of Planning. Aerospace Management,Fall/Winter, 1966.

61. Wilson, Ira G., and Morthann Wilson. Information,Computers and System Design, Wiley, 1967.

62. Young, Stanley. Management: A Systems Analysis.Scott, Forisman and Company, 1966.

COMMONWEALTH OF PENNSYLVANIADEPARTMENT OF EDUCATION

GROVER Mci AUG-L IVY7-52EE JUIIN Po thblER 7%0

SstACFO T A7

EtfCUTIVE? c 'PUt SECmAl

PASSBf~ 806 WN037HO IO 7uaow.1COI

PTATE AAS OF EOUCA TION

Pt A558L EVANS77 3787

PM)FIESSIONAL 1IANDANDE

PRACTICSAND r Amn71MAIVE MOFORA I'ON ANDP ATICESCDoM~imm%' ACTION OFFICE PUIKICAfTONSs

DA8E AUN, V " Ia rAl. AN)C ANN WTMER 'A.- GRFENAGIEA

FRANK 5 MANCHESTER 7 2t7j

DEPUTY COMMISSIOERMAARY I GERLACH 7 4ti5 ---

SATFn aTO EDUJCATION VAcert I e11SS 101EM UTV ACADEMT GEO001F 5AUElR5 j t. 2

IP As . At. ITA " 6MG INA 'NAIP 7 h, If

ASET. CosU(3686 FOR

CUT COMMCAIONR C6 101"A 6BYD 771 lS

PROJECT gIgMACM8CT CUMLCULU

1RVl.A I7 2177 '89

INTSEFDIATE UNITS -- C P II

SP ASsT FOREM1 CA TIGAL stAlCES

w Auf P, VOC ATIONA

PA8SWI 713

AUPPOSR

kIfOHN

3 3760

L INSTEJ00,0Po

A55T COMMISSIRFOR-PANNING AND EVLA-NFMWAN 00 It,7

HE SEEAB AR F27

MSERVICES

AU OF'" EDUCATION

ALI OfLDUCATION

AU OF/CTIONALTSERVICES

AU OfSERVICESO10SlIf08

OFFICE OF

OFFICE ofOMIClT@S ED

PAUL DAINf,7 3 22

OffoCs OFN408luPK9C 1CHOOL(1

MCHIEF4ANGA

MMF 8

J AMf, E E A. A

EDUCATIONAL

7 4234

AS' SA I7ITDEPUTV $FCM TANT

18*88 LISRA

kil AU 0 1- 1AAND UVALUATON

JMAU ?OfINFOWA T10NmmSYSTIM5

M1UM AU O

ILAI AN ARN

11TAF ERVICESW2t AM J$NES3 N6

ASSI COMMISSIONI

A71moD SASi7A

(.1O#IE MAliSHALLIsgom

JUSnICEMuLImAMNDERSON

7 ymE

FOR PUSI C AFF AINMARY 'DOFF

7 97 44

LEGILAIVIE FEDERAL LEASERVICES PN)GRAMS PATICIA DONOVANM *A TP KOCH JOAN 5CWAR77

7 2,44 7 7133

ER FOR HIGHER EDUCATION

JEROMf M 7'EGLER 7 5041

PUTT DotnlSSIONRIGL ADY5 HADY 7 7572

ASS? CommSOIgEIRMAROLD C)( W150p

COONDINATOWFOA

HOWER EDAJCAT~IO

CONkAD JONE$

7 1343

umaU o Timooe

CIRT1ICATIIR)NAD CDN7GAN

7 5105

PROPOSED I JULY 1976

Appendix A

Appendix B

Bureau of Information Systems

DirectorSeon Cho

Assistant

IP.

Planning andCoordinating Unit

Data Base CoordinatorInformation Systems

Planning Specialist

BureauonE

Voainl dct2

Divisionof

Research

ResearchCoordinatingUnit

Researchand

Developmenl

Divisionof

EducationalSta sties

Dean Hartman

In-house TechnicalResource Function

a /Higher EStatisti

Bas c Ed.Statistics

PDE/Activities

PSERBActivities

VEMAIS

Data rtingCollection

d.

Foi/Dat aControl

Divisionof

Computer Services

Al Azar

-88-

Appendix C

The Subsidy Formula

A. The Base Subsidy ( 87% of total subsidy)

ApprovedBASE = MIN Instructional Expenditure

LK- WADM750per *ARWADM

*WADM

1. Approved Instructional Expenditure - totaldollars to be spent by a school district oninstruction.

2. WADM - Last year's Weighted Average DailyMembership (maintained by Child AccountingDivision)

Kind of Child

half day kinder-garten

full time K-6

secondary

3. AR - Aid Ratio

Weight (unchanged since1966)

0.5

1.0

1.36

District Market Value/WADMAR = 1 - State Market Value/WADM

Market Value - dollar value of district's real estate

computed yearly and certified by: State Tax Equalization

Board**. Most recent year's data used instead of calculating

future values. Announced 6/30/n for year n-l.

** currently defunct

a

-89-

Note - Income Level is being phased into Aid Ratio

formula in conjunction with Market'Value

(e.g. 75% MV & 25% Income)

- Only 85% of district Incomes are currently

accounted for due to acquisition errors.

AR is never less than .10 (i.e. district never

gets less than 750/WADM)

The .5 is a distribution constant used since

1966

4. BASE can only be greater than or equal to

amount received per WADM in 1971/72 (base year

rarely changes)

B. Population Factor - Density

1. Density - if district has 10000 people/sq.mile

it receives: $250 * mAX [AR, .375] * WADM

- square miles computed by Bureau of Internal

Affairs

- Number of people-converted to district from

1970 census

- $250 has been constant over time

2. Super Density - if district has > 50,000 WADMs

it receives: 19% of Actual Instructional Expense

- the 19% has been a constant over time

-90-

3. Modified Density - used for districts with

under 10000/sq.mile

population/sq.mile ,10,000 * Density

4. Modified Super Density - if population <

10000/sq.mile and has > 50,000 WADMs it

receives:

population/sq.mile50,000 * .19*Actual Instruc-

tional Expense

5. A district can receive only one form of

Density Aid

6. Modified densities insure that once Density

Aid received, it will always be received;

even if population distribution changes over

time

B. Population Factor - Sparsity

1. Sparsity - if < 50.people/sq. mile a district

receives: $250 * AR * WADM

No minimum AR

2. Modified Sparsity - if < 100 people/sq.mile a

district receives:

2 - population/sq.mile) * Sparsity50

-91-

D. Poverty

1. Poverty Allowance per pupil to district

a) # of students ( age 5-17)

belonging to families making

income <*2000 - comes from 1960 or 1970 census

b) # of students (age 5-17)

belonging to families receiving

) $2000 in Aid to Families with Dependent Children

( data comes from Welfare office on tape)

can use either present AFDC or 1972 AFDC

c) calculate a total number of poverty kids and

multiply by $165 to get poverty subsidy

d) all districts receive some poverty subsidy

-92-

Appendix D

Three Examples of Proposed Changes to Subsidy Formula

Scenarios - proposals submitted to, statistics group

- test results needed within 1 hr - 1 day

- Results shown by: school district, county,

legislative district.

I. Parameter Change to Basic Formula.

A. Change AR to include Income along with

market value

B. Change maximum amount per WADM in basic

formula from $750 to $900

II. Union Proposal

A. 1.

2.

- New Model Required.

Rank order districts by WADM expenditures

Establish median WADM expenditures(round to $50)

B. Create 4 categories below median, at $50

intervals

(i.e. M, M-$50, M-$100, M-$150, M- $200

where M = Median WADM expenditures)

-93-

C. Districts qualify for special subsidy based on

"local effort" defined as:

mills on (total taxes collected for school purposesmarket valve per district)

( market value of district)

D. 1. Rank order districts based on: mills on

market value

2. Establish the median mills on market value(mm)

E. For each district:

1. if district collects 30% greater than mmdistrict receives (median WADM)

2. if district collects 15-29% GT mediandistrict receives (median WADM -$50)

3. if district collects 15% below to 15% GT median,district receives (median WADM -$100)

4. if district collects 29% -14% below median,district receives (median WADM-$150)

5. if district collects 30% or more below mediandistrict receives (mediam WADM-$200)

F. Bootstrap: Any district that is spending less

than (median - $200) per EADM,and is making at

least a -median local effort (i.e. mils on market

value is GE. to Median) district shall be con-

sidered to be spending (median $200) per WADM.

III. Governor's Proposal - Adds New Components to Base

Formula

A. Urban Assistance Component

-94-

1. If within a school district, there exists

a City of General population GE 40 K,

district will receive: $5/capitaor

$8/capita ifPhiladelphia orPittsburgh

2. No school district will be allowed to

receive more than 60% of the total Urban

Assistance given to all districts

B. Aid to Low Wealth Districts Component

1. If Aid ratio. is greater than 0.7, and

there are no sparsity payments of any kind

within the district, the district will

receive per WADM:

$125 for AR & .78

$100 for .75 ± AR & .78

$ 75 for .72 i AR 4 .75

$ 50 for .70 t AR 4-.72

2. To qualify, district must have 4 mills on

market value.