Ann F. Trost
University Registrar
Valparaiso University
Kretzmann 102
Valparaiso, IN 46383-6493
Phone: (219) 464-5212
Fax: (219) 464-5381
E-mail: Ann.Trost@valpo.edu
J. Michael Yohe
Executive Director, Electronic Information Services
Valparaiso University
Kretzmann 134
Valparaiso, IN 46383-6493
Phone: (219) 464-6763
FAX: (219) 464-5381
E-mail: Mike.Yohe@valpo.edu
Many colleges and universities have converted to new administrative
systems, and many of them have made presentations at various
conferences. Why is Valparaiso University's experience any different?
We haven't done the job overnight. We've been at it formally for nearly
two years; informal discussions, meetings, and some preparation have
extended over four or five years. At the same time, people who have
been involved in major conversions and know something of our starting
point have told us that we've moved along remarkably quickly.
Moreover, the atmosphere has remained generally positive and working
relationships have remained collegial through the difficult process of
implementing the new system.
We believe the things we did right and those that we didn't can help
others bridge the numerous chasms that obstruct the path to a new
administrative system.
There is one principle that undergirds our successes: this is about
people, not technology.
Only in the context of a well-defined sense of purpose can such
a project hope to be successful. You need strong support from
the highest levels of administration; and the campus as a whole
must buy into the project concept. Some offices may even need
to sacrifice comfort and benefits of the legacy system(s) for
the common good. A shared vision of overall institutional
mission and direction -- as would develop in the strategic
planning process, for example -- fosters the needed spirit of
teamwork.
Our experience:
Ever since our current President was installed in 1989, he has
worked for an integrated administrative computer system. The
1991-95 strategic plan both reaffirmed the shared vision for the
University and identified a campus-wide administrative system as
a major objective.
Take your cue from Madison Avenue: to get people's attention,
communication needs to be frequent, repetitive, and perhaps even
annoying.
Use electronic communication to its fullest: e-mail; shared
directories; intranet spaces, and so on. It's fast, efficient,
self-documenting, and (relatively) nonintrusive.
Face-to-face communication is vital, though, to feed the spirit
of teamwork and collegiality. Meetings, workgroups, and one-on-
one sessions are all needed; indeed, the latter is the only
method of communication that will really work in some situations.
That said, communication only lubricates the machinery; it
doesn't provide the fuel. Time spent communicating is time spent
not implementing; both those who are designing the processes and
those who are engaged in the heads-down "grunt work" need to be
spared unnecessary interruptions.
Our experience:
We used mail lists for each committee and subcommittee; a shared
network directory for process mappings, meeting minutes, drafts
of tables, error reports, and more; and an intranet Web site for
posting weekly status reports, minutes of the weekly core team
meetings, and other information of interest to the broader
community.
We meet weekly to keep each other up to date on our individual
problems, progress, accomplishments and discoveries. This is
important to keep each other's spirits up and renew our
determination to see the project through.
Someone once handed us a tied bundle of sticks and asked us to
break them. We couldn't. He then took the bundle, untied it,
and easily broke the sticks one by one. The ties of community
are vital in this enterprise. They are built by collegial
problem-solving; working with colleagues; mutual support;
expressions of appreciation -- deliberate and repeated; open
expression of concerns and frustrations; and, yes, celebration.
Community needs to include not just those who are working on the
project, but the entire campus community. Those institutions
fortunate enough to have a President who continuously builds
community have an incalculable advantage.
Don't expect those who aren't directly involved in the project to
have an inkling of what's involved, though. They won't; they
can't. And part of preserving community is knowing how and when
to bite your tongue.
Our experience:
We named ourselves ACT -- Administrative Computing Team -- to
convey the spirit of cooperation and community in our working
toward a common goal. And we kept that commitment when we worked
in smaller groups (also called teams).
A lot of informal, one-on-one encouragement, training, and
explaining has taken place and will continue to do so. New
bonds of friendship, support, and understanding have formed and
strengthen our determination. An understanding of how the
different parts affect each other and fit together has developed
and reinforces the team effort.
If community ties individuals together, maturity is what makes
them fit into a neat package.
The members of the community need the maturity to take
responsibility for their own actions; to admit mistakes; to back
up and get a fresh start when necessary. They need to offer
criticism gracefully and receive it graciously. This project is
hard work; there is no easy way out. There is no sense in making
it even harder by wasting time and energy trying to cover up or
pin blame on others.
It is important, even -- or especially -- in the midst of the
pressures of such a project, to remember to keep our lives
balanced. Or, should we say, to insist that others around us do
that, so someone will insist that we do. Left to our own
devices, most of us won't.
Our experience:
Sometimes key administrators haven't understood why their area
didn't get priority at the time they wanted it. Generally, these
issues have been resolved rather easily by face-to-face
communication. We've had only one mediation meeting, which
addressed the issue at hand and also strengthened our resolve to
try to forestall such meetings in the future.
Project planning is essential. You need to learn what tasks must
be done; in what order; and how long each can be expected to
take. The vendor may be of some help, but by all means use your
personal networks -- everyone on the team. Our experience
suggests that not all of the vendor's employees have been through
a conversion/implementation.
Establish a timetable that is realistic, flexible, and allows for
delays. Include plenty of time for training (and assume there
will be delays there, too); for scheduling vendor consultants;
and for redoing things that didn't work the first or second time.
Again, your friends are a good source of information on the
particular pitfalls of the system you select.
Our experience:
Our timetable was ambitious and required a *lot* of hard work in
too short a time, with no "buffer zones." Thus, delays in one
area affected completion of tasks in another.
We tried hard to stick to the timetable we established, but at
the expense of long days, long weeks, and limited time away from
the task. Some things slipped, but we met our goals for
financial systems (July 1998) and student systems (fall term
1999).
We lay out schedules and plans and budgets, only to have them go
awry. We know that will happen; the question is, how will we
respond when it happens?
Complaining doesn't accomplish much of value. Encourage a positive approach:
There will be problems. The approach to their resolution tends
to be a self-fulfilling prophecy. A "can-do" attitude, does.
Our experience:
Of course we wish that we had more time, more money, and more
staff. But we have done well with what we have and continue to
find ways to adjust and adapt and help each other along.
Momentum -- the natural tendency of an object in motion to
continue to move in the same direction -- and inertia --the
tendency of an object at rest to remain at rest --are forces as
powerful in the human psyche as they are in the physical world.
People don't want to change. Most won't phrase their feelings
exactly that way, though; more commonly, we hear "this doesn't
meet my needs" and similar rationalizations. One of the first
obstacles encountered in this process is getting buy-in from the
campus community.
Bridge: Needs assessment and consensus building.
This was about 95% successful. We started with a large task
force; identified teams for Institutional Advancement, Student
Services, Finance, Human Resources, and Technical; and brought
team leaders and other resource people together as a Core Team.
We initially omitted some key players -- Physical Plant, for
example -- but added them later (though not before our omission
caused ripples).
By the time we were ready to take on the project, most users had
already recognized the need to change. The hardest offices to
convince were those using legacy systems which had been
specifically developed and tailored to their needs.
If you are moving to an integrated system for the first time, be
aware that the culture change will be at least as difficult as
the technical implementation. People on campus may be used to
having complete control over "their own" data, and may also be
used to making major changes without any need to coordinate with,
or even notify, anyone else. Even if everyone buys into the
project, habit alone can go a long way toward corrupting the
best-laid plans.
Bridge: Enlightened self-interest
This was an oops. We thought we had it covered, but
underestimated force of habit and overestimated campus
understanding of our rhetoric about the advantages and
requirements of system integration. We probably also
overestimated the effectiveness of our communication.
A campus culture will not change overnight. One office developed
tables for their use that had implications for institutional
research and the way data was to be collected and reported later.
Because these other interests were not consulted, we had to
backtrack and rewrite the tables. When offices are not used to
sharing databases, it is difficult to instill the habit of
communication and collaboration.
Ownership (read power or control) is hard to give up if it's
always been yours.
Expectations beget ulcers. Let them be someone else's. Some common ones (and you can add others):
Add the natural viewpoint that "my office and my work are the
most important," and the natural conclusion is that all it should
take is a finger-snap to resolve any difficulties or shortcomings
that arise.
Bridge (oh, all right. Tightrope): Reality.
Our experience:
Our sense is this started off on the right foot. After a couple
of years, though, we found patience wearing thin in places;
primarily, it seems, where there was misunderstanding or perhaps
nonacceptance of the nature and extent of the work that would be
required of individual offices.
We did celebrate our milestones in several ways: chocolate
surprises at weekly meetings; annual picnics; lacquered cookie
bouquet and other floating trophies; T-shirts; birthday mementos;
"campaign" buttons; and other tangible "rewards" for progress.
The vendor you select should be the one who can best meet your
needs; but those on your campus who have experience (or friends
who do) with the kind of system you're seeking are bound to have
opinions, pro and con, about various vendors.
Usually, strong opinions are based on personal experience. Even
so, beware. On one occasion, one of the authors was excited by
the opportunity to buy a system he had used in another place --
until he found that all the things he liked about that system
were local code, and the "vanilla" system was completely
different from what he had experienced.
Friends' opinions, pro and con, are valuable, but not necessarily
applicable. Bear in mind that they are reacting to their own
situation and their own customization (and release) of the system
they are using.
Other influencing factors may be the buzz-word quotient,
popularity or perceived sophistication of certain vendors, vendor
promotional materials, or ties to specific hardware, operating
systems, or database software.
Bridge: The Request for Proposals (RFP) and strategy
Replace subjectivity with objectivity: write down everything you
need or want, and let the vendors tell you how close they can
come to complying. There are many RFPs available and a number of
papers have been written about preparing an RFP. Some pointers
that may be a bit on the unusual side:
This part of the project worked very well for us. We "borrowed"
RFPs from a couple of other institutions and merged them, adding
some personal experience. Then we turned the Core Team loose on
it. The result was reasonably complete, though we left out
language specifying ease of use in some important areas, and
neglected to specify the amount of background and experience we
expected of vendor consultants.
Our RFP was extensive, and space does not permit further
discussion. We will be glad to share the RFP and the evaluation
spreadsheets with other colleges and universities.
You are also likely to be under pressure from vendors to make a
subjective selection. Some vendors may offer "sweetheart" deals
if you forgo comparisons; others may lobby with your upper
administration or board.
The sales people are there to curry your favor. They may want to
pick up dinner tabs, shower you with gifts (emblazoned with their
logo, of course), or whet your appetite with visions of the
future according to their corporate Nostradamus.
Bridges: Maintain objectivity
Another thumbs-up. We had opportunities to frustrate our
objectivity, but stood firm. Support of the upper administration
was important here.
We had a request from one vendor to spend a week on campus to
"get to know us" better so that they could better meet our needs.
We declined, indicating that we would have to allow all vendors
this opportunity and it would not fit our time line.
If you don't disqualify proposals that fail to follow your
outline, you'll find that proposals aren't comparable and
evaluation will be a nightmare. Some vendors won't answer the
questions you asked (and will answer a whole bunch you didn't
ask); and it will be almost impossible to dig the needed
information out of their responses.
Bridges: Critical Analysis, Site Visits and Return to Reality
Here's where your care in assembling the RFP pays off. You will
be able to create an evaluation instrument (preferably, at the
same time you write the RFP) that can help reduce the confusion
and promote thorough evaluation.
Some pointers:
This worked well for us. Particularly useful was the evaluation
scheme and the spreadsheets to support it. Weighting schemes can
be difficult to build; we were careful not to try to assign
relative weights to every pair of minor points in the entire RFP.
Instead, we structured the proposal as a tree; the main proposal
had several topics, and each of these had subtopics, and so on
until all branches had been extended as far as necessary. Then
relative weights were assigned to the subtopics at each level.
The only relationship between "leaves" belonging to different
main topics was the relative weights assigned to those main
topics.
Each member of the Core Team received a copy of each
proposal and evaluated the proposal by assigning a numerical
"grade" to each item. The evaluation spreadsheet formed the
composite score.
There were few real surprises; most members of the team agreed on
most points, but the scheme gave the evaluation credibility in
the task force and in the University as a whole.
You've selected your new system. You're on higher ground now, which
means the chasms deepen. The work begins; the change looms; and fear
strikes at the hearts of nearly everyone.
We will mention only in passing the sheer volume of work that needs to
be done. If you've been there, you understand; if not, we can't
explain. Count on lost vacation, lost weekends, long days, and large
antacid bills.
There are a couple of avoidable sunderings of the path, however.
At this point, nearly the entire campus is confronted for the
first time with the reality that they will be leaving the
familiar habitat and entering uncharted territory. That
realization produces anxiety in all of us; some handle it better
than others. Expect to hear protests such as, "The new system
can't do what I need done" (whether they know that for sure or
not).
The Bridges: Training, Successes, Mutual Support
The major problem is fear of the unknown; so it follows that the
way out is to make as much known as possible, and allay fear
where territory remains uncharted.
We thought we bought a generous amount of training. It wasn't
enough; it wasn't timed properly; and we didn't immediately
follow it with hands-on experience to reinforce it. If we could
do it over, we'd hire and train a full-time trainer for at least
the basic stuff everyone needs to know.
One difficulty we ran into was scheduling the training at an
appropriate time. When the trainer could come, we were extremely
busy; we when had time for training, no one was available to come
from the vendor.
Implementation is not easy. Errors in setting up the system,
incomplete conversion specifications, dirty data in the legacy
system, and misunderstandings about the uses of fields in the new
system will all take their toll.
In addition, there will be pressures to make the new system look
(and maybe even behave) just like the old one; time spent doing
this or resisting it will delay implementation, too.
Bridges: Method
Minimizing implementation problems boils down to one thing: be
excruciatingly methodical. Inhumanly methodical.
We recommend using modern tools such as intranet spaces for
developing codes, procedures, and other implementation
activities. This makes the information instantly available to
everyone, and enables the use of powerful global search and
extraction capabilities which may not be available within the
system.
Some additional pointers:
We had some useful methods and organization; we just didn't start
early enough. We also didn't have a complete data element
dictionary for the legacy system, so found ourselves groping in
the dark some of the time. Our first conversion was as close to
disaster as we care to get. After that, we were more methodical
in our conversion mappings and things went much better. We had
some delays, though, because we did not understand the vendor's
"source" file for conversion was what we were calling an
"intermediate" file; other delays because of misunderstandings
about who would do what or about the meaning of data fields; and
still others due to changes we made in codes after the conversion
was mapped but before it was run.
Implementation is difficult, even if you have superusers who are
familiar with the data and its location in your legacy systems.
You have to make decisions about where the data goes before you
know the new system very well. And the vendor's mapper, who
knows the new system, will not know your legacy system setup or
organization. The best advice we can give: question
everything!
You have arrived when the things that are supposed to work, do;
existing processes become streamlined; and new processes become
possible.
You will never be "finished." One of your objectives
was undoubtedly to team up with a vendor who would keep you
up to date with technology; and this means frequent change.
You will discover new ways to use the system, and applications
that had not been imagined. These additional applications will
keep the pot stirred.
Institutional business practices change, and may change more
frequently now that offices can write their own rules and
reports rather than relying on the central programming staff.
Our experience:
We will probably spend the next year getting our processes up to speed on the new system, continuing to evaluate the way we do business, and catching up with report writing. Ten years worth of queries cannot be replaced overnight, but they can be analyzed for their logic which may or may not fit the new system. We will maintain our weekly Core Team meetings to share the joy of discovery (and the agony of defeat, if necessary). By this time next year, we'll be through the really hard stuff at least once, will feel much more comfortable with the new system, and will have developed a terrific support group to get us through the tough periods.
We wish you well on your journey!
October 27, 1999