The Decentralization of Applications Groups at Stanford: A Five Year Retrospective

|-------------------------------------|
|  Paper presented at CAUSE92         |
|  December 1-4, 1992, Dallas, Texas  |
|-------------------------------------|



THE DECENTRALIZATION OF APPLICATIONS GROUPS AT STANFORD: 
A FIVE YEAR RETROSPECTIVE

A panel discussion with

Ann Mueller, Manager of Systems for Administrative Resources
Marick Payton, Director, Network for Student Information
Gerry Weitz, Director of IS, School of Medicine
Judith Yarborough, Manager, Financial Information Systems and Services
Stanford University



ABSTRACT

The four panelists have been managers of applications programming at 
Stanford under the prior centralized organization and during the five 
years since this function was decentralized into the separate business 
lines. They will review the history of this organizational change and 
reflect on its advantages and disadvantages as they have observed them.
 
-----------------------------------------------------------------------


Ann Mueller, Manager of Systems for Administrative Resources

Context

In mid-1987, when application programmers separated from the central 
Information Services organization and were distributed to various 
business units, our group aligned itself with the administrative 
services component of the university. The unit which I came to manage 
ultimately supported systems across multiple vice-presidential areas 
including Administrative Resources (Procurement, Stores, Housing and 
Food Services, Conference Office, Environmental Health and Safety), 
Planning and Management (Facilities Project Management, Operations and 
Maintenance, Transportation), Human Resources (HR Systems, Salary 
Management), Finance (Accounts Payable, Reimbursements, Travel), and the 
Stanford Management Company. 

In addition to our interactive, mainframe-based applications, our group 
provided all development and maintenance support for the inventory 
management/distribution and EDI systems running on the Stores System 38 
and ad hoc support to work order/job cost applications running on 
Operations and Maintenance's HP9000.

During these years, we aggressively developed "central administrative" 
systems and associated electronic forms, inquiry, and reporting 
applications for the use of all university staff engaged in 
administrative activities. In support of these department-oriented 
products and services, we provided a variety of user documentation, 
training classes, and consulting. At the peak of these activities (FY 
90/91), our group responded to over 6,000 email and phone consults and 
conducted 52 training sessions with a total attendance of over 1,200 
staff members. And, as the use of electronic forms and services became 
the preferred way of doing business between departments and central 
offices, the annual transaction volume generated by departments using 
our systems went from 65,000 to over 300,000.

Our client-base rapidly shifted from a narrow band of central office 
"system owners" to a diverse community of over 2,500 people, primarily 
staff but also faculty and students. We took on new roles as 
facilitators between central and departmental needs and wants. We 
learned how to become an advocate for the interests of the departments 
in their relationship with central administration and how to ameliorate 
differences between these two constituencies in the process of system, 
product, and service development.

Staff

At the time of decentralization, seven programmer/analysts an 
administrative support person, and a one-third time manager were 
allocated to this group. Over time, our numbers grew to 11 people as we 
added one programmer/analyst, a full-time manager, and a staff position 
to work with departments and central offices on the external design and 
requirements for our departmental applications, to write user 
documentation, to construct and teach courses, and to provide email and 
telephone consultation.

Issues

Staffing: In industry, a typical decentralized IS unit is comprised of 
50-90 people allowing for a mixture of skills, levels of abilities, and 
flexibility in resource allocation. Few economies of scale can exist in 
an IS organization of 10 people and one's ability to leverage resources, 
either staff or the university's significant investments in systems and 
information is severely limited.

Although turnover is and has been extremely low by any standard, most 
people left one unit only to join another decentralized unit or the Data 
Center, where they perceived a greater opportunity for career growth 
and/or advancement. Typically, these people were high potential or high 
performance individuals.

Alignment and Ambiguity: At the highest levels, the organization of the 
university has changed over the past years while the IS organizational 
structures have remained relatively static. As new administrative areas 
emerged, staffed by new senior officers, IS units aligned themselves 
(for better or for worse) to these new vice-presidential areas. We found 
ourselves marching to new, and different drummers while long-term, 
strategic visions for IS grew more and more faint. During this time, 
especially during senior management transitions, long periods of 
ambiguity, without global initiative or directive, settled over IS 
units. 

Funding: During the past few years, in pursuit of an aggressive 
development cycle (six programmers assigned to development and only two 
to maintenance), our liability to support and maintain the systems we 
have put into production has grown to enormous proportions.

However, base funding for the ongoing support of these systems had been 
inadequate or nonexistent. Budget cuts due to repositioning efforts have 
further eroded our existing base. This remains a major, unresolved issue 
for most IS units.

Standards: We no longer subscribe to a common set of standards in our 
use of technology, in the funding and development of systems and 
services, in the measurement of our work, in the evaluation of our 
progress, or even in the performance of our staff. Each decentralized IS 
unit has established its own cultural identity. 

New Technology: Many of us believe that the technology (mainframe-based, 
SPIRES proprietary DBMS) which has served us well over the past 15 years 
is reaching the end of its productive life cycle. As we look towards a 
new architecture (micro-based, client/server) to meet the future 
business and information needs of the university, we recognize that we 
must acquire a wide variety of new management knowledge and technical 
skills to be successful and expedient in this transition. Our small, 
independent IS units (engaged in day-to-day operational activities) do 
not have the staff, time, money, and perhaps even the necessary skills 
to initiate a systematic business and/or technology migration.

Conclusion: Change is inevitable and things will no doubt change again. 
One might speculate why we have been able to accomplish, collectively, 
as much as we have over the past years. First, we all knew each other 
and respected each others accomplishments prior to decentralization. 
Those relationships have served us and the university well. Second, our 
staffs are dedicated and hard working. Finally, five years ago, at the 
time of decentralization, we took away with us a well-formed strategic 
vision about where we wanted to be at this point in time and we have 
collectively and individually pursued that vision.



-----------------------------------------------------------------------


A SUCCESS STORY FOR DECENTRALIZATION

Marick Payton, Director, Network for Student Information, 
Stanford University

Stanford's decentralization of business application programming groups 
some five years ago--the movement of management authority, budget and 
bodies from the Data Center to the VP areas--has been very fruitful for 
the offices of the Vice Provost for Student Affairs (VPSA) and its 
system group, the Network for Student Information (NSI). Our business 
area, headed by the Vice Provost for Student Affairs, incorporates the 
offices of the Dean of Students, Undergraduate Admissions, Financial 
Aids, the Registrar, Housing and Food Service, Student Health, NSI and 
several other offices. Total staffing is about 600. NSI developed and 
maintains a custom, integrated information system to support the 
functions of these offices. NSI also supports the administration of 
graduate student admissions, aid and academic progress management by 
schools and departments and the student accounting functions of the 
Bursar. NSI has a staff of 19: 12 programmer/ analysts, four operations 
staff, one trainer/documentation writer, one administrative assistant 
and a director.

There are a number of consequences of the decentralization of NSI into 
its client business area that have increased its productivity. The most 
significant of these are:

   --We know our clients and their businesses better. Being co-located, 
     these businesses go on all around us. Our staff support them year-
     after-year.
   --We have a stronger identification with and more allegiance to our 
     clients. Part of this is organizational: We are managed by our 
     client organization. We and they perceive their business to be our 
     business. Part is personal: we associate with our business 
     colleagues day-to-day: in the hallways, the restrooms and staff 
     lounge as well as in their offices. 
   --We are better able to bring systems expertise to management 
     deliberations at both the VP level and in the individual offices, 
     exercising more influence on strategic planning, work design, 
     hiring decisions, etc. As Director of NSI, I participate with my 
     fellow Directors and Deans in the VP Executive Committee.

These effects are well illustrated by three major projects we have 
undertaken in the past three years. The first of these was support for 
the decentralization of graduate student affairs. The parties who made 
the decision to close the central Graduate Studies Office and 
decentralize its responsibilities had little understanding of the scale 
and complexity of the functions involved. Planning, management and time 
frame for this undertaking were all seriously inadequate. We were given 
responsibility for developing new computer systems to enable performance 
of the admissions, aid and degree-progress management by the several 
hundred staff in academic departments. We committed ourselves, on our 
own initiative, not only to redesigning all the screens and 
documentation to make them suitable for use by this large number of 
inexperienced staff, but also to complete automation of the graduate aid 
process with interactive linkages to the personnel and accounting 
systems and incorporating the University's relatively new forms-routing 
and electronic signature capabilities. This decision to take on a 
greatly increased work-load (a year of 60-hour work weeks) and 
considerable additional risk with no additional staffing was made by my 
staff because they felt their clients needed the efficiency that such a 
completely automated and integrated system would provide. And, when a 
long period of uncertainty about who had what policy authority in the 
new decentralized order left critical functional specifications 
unresolved, the NSI staff stuck their necks way out and just made the 
best judgment they could so the system could be functional by the 
critical deadline. Is this the right way to develop systems? Absolutely 
not. But, by "busting ass" and "bending rules," we kept a lot of people 
at the bottom of the ladder from drowning under a tsunami of poor 
planning and management from those at the top. I believe my staff made 
these extraordinary commitments because of the special allegiance they 
have developed to their clients. 

More or less concurrent with the University's decision to decentralize 
graduate student administration, major budget reductions were made for 
all central administrative offices. In reaction to these cuts, the 
offices of the Registrar, Housing, Financial Aids and the Bursar decided 
that they could achieve significant cost savings while improving service 
to students if NSI could create a system to enable students to do much 
of their business with the offices through on-line query and update 
access to their individual database records. This student access system, 
the second project I will describe, had to be sufficiently intuitive and 
self-guiding that no training was required, if the budget reductions 
goals were to be achieved. And, all students had to use the system. This 
seemed a wonderful opportunity to use the client/server technology under 
development by our Data Center to enable use of a graphic user interface 
(GUI) to the mainframe database. We entered into a partnership with the 
Data Center to do so. Their primary objective in this collaboration was 
to develop a set of conventions for GUI design that could be used for 
other applications at Stanford. There was tremendous excitement in both 
organizations over being involved with this state-of-the-art technology. 
We spent six months working intensely with the DC on interface design 
and the client/server architecture before concluding that the risks that 
all this "new stuff" might not work, let alone work in time, were 
greater than our clients could afford. We made a wrenching turn of 
direction and developed the system as a guided, line-by-line interface 
supported directly on the mainframe. Then, the staff on this project 
spent the next year working 60, 70 and even 80-hour weeks to make up for 
lost time. Throughout this development effort the NSI staff and the 
responsible staff member from the Registrar's Office worked cheek-to-
jowl. I credit our recognitionŠin a timely mannerŠthat our desire to use 
the technology of the future was creating an unacceptable risk to our 
clients, in good part, to sensitivities developed as a result of being 
"one" with them organizationally. Ditto for the willingness to work far 
beyond the call of duty. Incidentally, Axess has been a tremendous 
success.

My last example illustrates the enhanced ability to bring systems 
expertise to business management which can result from the merger of 
business systems support into the client business line. We had struggled 
for years to develop solid automated support for one of our client 
offices with little success. The problem was primarily that the office 
lacked any real systems savvy. This problem was compounded by a 
management culture that fostered guarding knowledge--knowledge as power-
-rather than sharing it. When an opportunity to hire a new associate 
director arose, I was able to get myself and my programming manager onto 
the interview panel. And, when it appeared that the job was going to a 
candidate whom we felt would bring little relief from the problems of 
the past, we were able to exercise sufficient influence, on both the VP 
and the office director, to hire the "second" place candidate, whom we 
felt would bring great systems strength, as well as open up the 
management culture. This new associate director and I were able, 
subsequently, to develop a plan to completely re-engineer the way the 
office does business and have just secured funding to implement this 
plan, including extensive system development to support the new way of 
doing business.

Clearly, there are disadvantages to decentralizing applications groups. 
Obvious ones are that it makes it harder to develop enterprise-wide 
strategic planning for IS and to enforce enterprise-wide technical 
standards; it may make it harder to integrate business systems across 
business lines; it may limit career paths for technical staff; it may 
lessen the chance for technical cross-fertilization between systems 
groups, and it may promote excessive conservativism about taking risks 
with new technology. My colleagues on this panel will no doubt add to 
this list. These are serious issues and they must be managed. However, I 
believe that, in today's business environment, described by Peter 
Drucker as "turbulent" and by Tom Peters as "chaotic" and exemplified by 
the examples given above, the advantages outweigh the costs. With 
business (academic business quite as much as commercial) facing 
constantly increasing competition, reduced resources, more regulation 
and demands for more accountability, business needs systems support that 
brings the business knowledge, involvement with business management, and 
intense commitment that decentralization of systems support provides. 
Such systems support can make a major difference as management copes 
with downsizing, new product and market development, work re-engineering 
and quality management. A critical success factor in achieving these 
outcomes is strong leadership and vision from the senior business 
management.



-----------------------------------------------------------------------


ORGANIZATION OF IS: A SCHOOL'S PERSPECTIVE

Gerry Weitz 

The question of whether to group business application programmers in a 
central IS organization or decentralize them into their client business 
units is interesting, controversial, and, I assert, will not solve the 
fundamental problems we face in the future. I'd like to look at the 
problem from another perspective, that of a information systems manager 
in a school.

Figure 1.(missing from text version) illustrates the difference between 
how a school or department views data and process and how the central 
administrative organizations view data and process.

The IS professionals are focused on serving the central administration 
and, through the central administration, the academic departments. They 
are not focused on serving the academic departments directly. 
Historically this made sense because information technology was too 
expensive to apply to the data and process problems of small, 
heterogeneous organizations. That is changing rapidly. We currently have 
needs in schools and academic departments to do planning and analysis 
that requires data across multiple central administrative organizations. 
If the promises of object oriented technology come true, we will be able 
to tailor processes to fit these small organizational units.

There are three questions I would like to raise to help think about 
possible future organization for IS professionals.


--Who owns the data?

In the past the data was "owned" by central administrative units. Even 
if they were styled as "data custodians" it was still de facto 
ownership. The responsibilities of ownership include definition, 
security, audibility, entry, access and storage. This was exercised 
within the vertical boundaries of the administrative unit with 
occasional weak integration with data in other administrative lines.

We now need data that is defined consistently, integrated, secure, and 
available across the whole institution.


--Who owns the process?

Information processes were also seen to be owned by central 
administrative units. Finance owned the payroll process so they picked 
the system to be used and, if so enlightened, sought buy-in from 
academic departments and schools. This was really the only practical way 
to do business in the past. Now, academic departments and schools are 
building their own processes and need to have influence on the systems 
that are implemented by central administration.

When the object oriented technology comes to fruition, will we have the 
ability to hook processes together like tinkertoys? If so, then the 
central administrative organization will not be the sole owner of the 
information systems process; the schools and departments must also have 
their say.


--Who owns the desktop?

Historically, the central IS organization has provided the "desktop" as 
a view into central data and processes. But the desktop has evolved from 
a timeshare terminal to a independent microprocessor that integrates the 
data, processes, tools and information for an individual. It give us the 
ability to individualize our view of the information world. How can a 
central IS organization understand what is important to a large group of 
individuals dispersed across the University?

James Wetherbe of the Carlson School of Management, University of 
Minnesota, in an article "To Centralize or Decentralize," Information 
Week, September 19, 1988, p. 74, wrote, "There are three factors to 
consider [to best decide what to centralize and what not to]: 
interdependency, homogeneity vs. heterogeneity, and corporate culture."

If business operations are highly interdependent, centralization is 
necessary. If interdependency is low, then if the business operations 
are homogeneous, centralization would make sense. Corporate culture may 
override other issues. Wetherbe adds one caveat, "But you should never 
completely decentralize planning."

Applying this reasoning to the situation at Stanford in conjunction with 
the questions posed above, I come to the following conclusions:

Data ownership should be centralized. We are interdependent on 
consistent, high-quality, available, secure data and should not leave 
that function to the uncertain administration of individual 
administrative offices.

Architecture, Technology, and Business Systems Planning should be 
centralized. This includes infrastructure standards, technology 
assessment, approved product lists, business systems data exchange 
standards, business systems process standards, and human interface 
standards. Again, this effects everyone and we all, central 
administration, schools and academic departments, need a voice.

IS professionals can be decentralized to their client organizations. It 
will always be important for IS management and professionals to have a 
close relationship with the people they serve. Their options for 
information systems, however, must be constrained by centrally enforced 
standards.

Finally, we have the question of the corporate culture for 
centralization or decentralization. With a new President, Provost, CFO, 
VP for Personnel Services, and VP for Student Affairs, it is anyone's 
guess as to what our corporate culture will be.




-----------------------------------------------------------------------


PANEL EVALUATION OF STANFORD'S FIVE-YEAR EXPERIMENT WITH 
DECENTRALIZATION OF BUSINESS SYSTEMS DEVELOPMENT AND MAINTENANCE

Judith Yarborough
Stanford University
Stanford, CA

In the early months of 1987, the process of reorganization the 
Information Technology function at Stanford began. One of the outcomes 
of that reorganization was the decentralization of the applications 
programming staff into the line organizations they served.

First, a look at how Information Technology was organized. Within 
Administrative Information Services (AIS) there were a director, five 
Assistant Directors, a Quality Assurance group, and a departmental 
support group. Under the Assistant Directors, there were nine 
programmatic areas, five of which focussed on the needs of a single line 
organization. Where there was a single organizational focus, the 
Assistant Director had a joint reporting relationship. The relationship 
made the Assistant Director responsible to both the Director of 
Administrative Information Services and to the senior administrator in 
the line organization.

For instance, the Assistant Director for Financial Information Services 
reported to both the AIS Director and the University Controller, the 
Assistant Director for Medical School Information Services reported to 
the AIS Director and the Associate Dean of the Medical School. The line 
office agreed to pay an annually negotiated amount for a stipulated 
level of application support services. So for instance, the Controller 
agreed in advance to pay for a staff of 16 programmers, 1.25 
secretarial/clerical help, and an Assistant Director.

AIS also offered application support on a chargeout basis through a 
group called Business Information Services. This group was designed to 
offered service to organizations that were too small to warrant an 
annually negotiated support agreement. Additionally, AIS supported a 
Community Information program, an interuniversity consortium of SPIRES 
users, and a group of microcomputer consultants called Departmental 
Information Services.

Information Technology Services had an advisory group called 
Administrative Systems Policy and Planning group (ASPPG) that acted as a 
coordinating body for administrative systems. Under the aegis of ITS and 
ASPPG, the University had selected a single data base management system, 
SPIRES (Stanford Public Information REtrieval System), and had 
promulgated the concept of University-level subject data bases. These 
two decisions had lead to the development of systems that made 
administrative information widely available in a common format.
With the creation of a Vice President for Information Resources, a 
number of changes occurred. Stanford Hospital became responsible for 
their own applications programming support so the Hospital Information 
Systems group moved physically and organizationally to the Hospital. 
Alumni Development Information Services became part of the Office of 
Development. Student Information, Services became part of the 
Registrar's organization.

Financial Information Services and Business Information Services staffs 
were reorganized so that one group reported to the VP of Business and 
Finance through the Controller and another group reported through the 
Associate Vice President for Administrative Services and Facilities.

Over the past 5 years, there have been a number of changes, both within 
technology units, but also within the University's senior management 
structure. The result can be seen in the following organization chart. 
But the basic principle of decentralized application development and 
maintenance still exists.

One further item of interest is that of the technical staff members who 
were part of the old Administrative Information Services unit, 80% are 
still at the University in a technical capacity and 57% are still with 
serving the same line organization unit (i.e. Office of Development, 
Controller, etc.)