December 1999
Volume 15
Number 9
Should We Customize the New AIS?
Recent articles in The Chronicle of Higher Education have looked at the woes of administrative information system (AIS) installations and in doing so, have broken new journalistic ground in naming names and reporting confessions of error. Many institutions now realize they misjudged the degree of risk associated with being first-wave adopters, which is not at all to say that they chose the Awrong@ vendor. Useful though these discussions have been, they have barely touched one of the most difficult and sensitive topics in the conversion from an existing AIS to its successor: software customization.
What=s wrong with customization? It is expensive. It disrupts and dilutes the quality of work that goes into what is already a difficult process of installing a new system. It adds greatly to the overall cost of ownership for new software by imposing additional support overheadCrequiring special attention whenever the baseline software is upgraded. It weakens the partnership with the vendor who also incurs greater future costs for ensuring compatibility of customizations with future baseline enhancements. It provides cover for our reluctance to manage our administrative units closely and challenge poor management among our peersC customization is a way to carry forward idiosyncratic or just plain arbitrary practices. Axiom: customization should be kept to a strict minimum and then managed aggressively.
Most colleges and universities changing software now are replacing systems they have used since they first adopted computer-based information management. Some of these systems have been in place for twenty years or more, which more or less corresponds to the Aliving memory@ of the institution. Looking back on the frustrations, embarrassments, and cost overruns from the troubled installation projects, it is interesting to wonder what part of the problems can be attributed to the surprisingly complicated and ambivalent ties we have to those old systems. Many administrators and staff have known no other computer systems. Almost all would be hard-pressed to distinguish between those elements of administrative practice that determined the characteristics of the existing software and where the software determined the practices. It is easy to surmise that if we were just now going from paper-based processes to the current generation of computer-based systems we would have an easier time of it. So, how much of the difficulty comes from undue influence of the superseded systems on their replacements? Or, from a human perspective: how much of the hurt is self-inflicted?
Mandatory or elective?
To be sure, when something like a Afit
and gap@ analysis takes place the new
software will lack some small number of genuinely essential functions. Putting
aside for the moment the more problematic calls and the many places in which the
new is just different, the question is why did those gaps not get identified in
the RFP? Did they not turn up in checks with peer institutions who have adopted
that software? How can major mis-matches emerge after purchase if the RFP was
properly focused and the vendor responses accurate? Nevertheless, they do occur,
and even if the RFP was reasonably well done it seems there is still a lot of
room for misunderstanding or overlooking requirements.
Whatever the cause, these are the mandatory and unavoidable customizations. They must be the subject of high-level project management attention from the time they are discovered. They also need to prompt a reassessment of project timelines and costs. And, finally, they each need to be acknowledged and reported as they arise, because otherwise they tend to be used later as alibis for a very different order of problems.
Turning from those faults that would bring the life of the institution to a crashing halt if not remedied (and surely these are few), we come to the heart of the topic: elective customizations. Why is the number of requested customizations generally so high? Reasons range from foot-dragging by administrative units who are really not Aon board@ the project or are so weakly managed that their staffs= wish lists are not rigorously winnowed before being passed on to the project management to premature conclusions about what the new software actually does orCworse yetCmisunderstanding of how old functions are in fact accomplished in new but different ways. All of these result from a sort of Ainertia of rest@: the future system needs to look like the old one because otherwise we would have to change the ways we work and think.
Even more flattering aspects of academic culture can serve to inflate the number of permitted customizations. For example, the degree of unit-level independence we like to think of as a kind of democratic management style leads us to defer too easily to colleagues= claims that their lists of changes are reasonable and worthy. In fact, we tolerate a live-and-let-live attitude by which we don=t challenge each other=s agendas. AStudents, top administrators, and even some of the faculty come and go, but we staff are here for the long haul and so need to live together.@ How much hard work do we evade under the justification of that axiom?
In truth, replacement of an AIS is a unique kind of event in the life of a campus of any size or complexity. No other project crosses so many unit boundaries and has as much ramification. As a result, we are not experienced or prepared to cope with the scope of this task. The selection process, whether done well or (more often) poorly, leaves us exhausted and consequently over-eager to click past the project milestones that look so promising on paper and so urgent in light of the price we have finally accepted. Into this scene then comes the flow of customization requests. We have already made the speeches about how these need to be kept to a minimum and how the cost of the project is already higher than anyone foresaw, etc. But in reality we are too willing to trade away concessions on customization in the name of keeping peace with everyone. Those who report relatively smooth (more or less on-time, on-budget) installations invariably cite minimal customizations, both necessary and elective, as key to that success. Conversely, nearly every nightmare project has an out-of-control customization story lurking at some level of visibility.
And what of the role of consultants in the matter of customizations? It has been noted that because consulting firms increase their revenue when they perform the code customization they might be in a conflict of interests when they are also advising the client on the desirability of code changes. Be that as it may, there is a deeper problem here. Where an institution does not have its own management discipline to limit change requests, the outside parties (consultants and vendor) might conclude reasonably that the customer has passed along to them the chore of keeping the various administrative units happy and will ultimately tolerate cost overruns in order to meet that goal. Axiom: you cannot outsource successfully management tasks you will not face yourself.
There are at least five strategies for minimizing the need to
customize and instead channel the interest in elective changes into more
productive and reasonable avenues. They are discussed here in order of
difficulty (and therefore also cost), from most to least.
Re-engineering. Here is a dilemma: software change is in itself an
all-consuming chore, which makes a concurrent effort to re-think processes seem
quite daunting, butC the other horn of
the dilemmaCwe also know the other
scenario that prompts re-engineering is a crisis of strategic dimensions. So,
pro-active re-engineering is probably only going to happen in connection with
software systems change if it is to happen in that mode at all. Instead of
thinking, Awe will look at those
processes that the software forces us to re-examine@
we might instead want to go into the AIS replacement thinking Aeverything
is open to re-evaluation, and we need to factor into the project the time to
carry out this process.@ Well, here we
run up against what is already the biggest tactical mistake we make in AIS
replacements: failure to see the need to add temporary staff so that those units
engaged in the change-over get enough relief from routine chores to devote
appropriate time and attention to bringing in the new system. They should also
have the same buffer in order to re-examine their processes and their wider
roles in the new AIS. Failing to create the time-release for rank-and-file staff
is one of the most common contributors to unsatisfactory projects. A pool of
temp workers to move from office to office as the installation unfolds would be
a reasonable way to enable the time investment for re-engineering.
Tailor, rather than customize. All of the systems on the
market incorporate extensive capability to define rules, populate tables, make
choices, pre-configure functionality, and specify values and parameters that
enable the software to conform to campus needs. The mental model of Aoff-the-shelf@
vs. Acustomized@
is twenty years out of date. No system is ready to run in Aoff
the shelf@ mode; they all require
tailoring to local needs before they are ready to run. The tailoring issue is
one of degree: whether to tailor aggressively during installation or (the other
extreme) to set only the necessary choices, values, and parameters and take the
defaults for most of the rest. While tailoring does not solve the case of a
severe gap in functionality (and therefore the need for a customization), it is
clearly wasteful to take the route of customization where some combination of
tailoring adjustments would suffice. Tailoring, to be clear, does not involve
re-writing the vendor=s code;
customizing does.
Postpone customization. Customization of code introduces delay in the
project schedule, and it might be unavoidable if there is no acceptable
work-around for the missing functionality. But if a code module can go into
production mode without customization against a promise to reassess the need for
custom changes after it has been in operation for a while (and the project as a
whole has been able to progress), that would be an alternative to deferring
implementation until after a pre-emptive customization.
While this option is not always possible, where it can be
implemented it has two major benefits: the project is less disrupted overall and
the administrative unit has the opportunity to know their module of software
more thoroughly before returning to the customization question. If the decision
is to customize, surely it is now made on better information and experience. If
it proves unnecessary, so much the better.
Create subsystems. Commercial AIS packages are actually whole system
environments in which the same tools the vendor used to write the applications
suite can be used by the customer to write extra, independent, free-standing, or
auxiliary functional units. An alternative to some customizations is to develop
additional code that remains independent of the base code and will not interfere
with the vendor=s subsequent upgrades
and enhancements. But, like customizations, these additional code units will
need to maintained and upgraded as the base package evolves. No commercial
system is going to meet every locally specialized need in any event but will
have to communicate (exchange data) with an increasing number of other systems
(e.g., passing Apatron@
information to the library OPAC). From this need to use the new AIS=s
tool set to interface with other programs, it is a small step to thinking about
supplementing the system=s
functionality by building new code units with Ahooks@
to connect back without intruding on the baseline code.
Train more extensively. If we compare administrative units who are most
successful with the soon-to-be replaced system with others that have always
struggled with it, one thing we will find is that the more fortunate have the
ability to find work-arounds and alternative methods within the existing
functionality. They know their system modules better and have a can-do attitude
towards it. It stands to reason that this approach and mind-set would be a good
thing to encourage and support from the outset in the next AIS. A few extra
training sessions are unlikely to make over an IS-challenged unit, but the
change of AIS is a good point to draw a line after which the standard of system
usage will be higher. The institution fails to get the best return on its
investment in the new system if it leaves the standard of engagement and
productivity to local option.
Good customer service
What was F.W. Woolworth thinking when he (reputedly) said, ARight
or wrong, the customer is always right@?
That is a serenely self-confident statement, implying Awe
have everything we anticipate might be asked of us and can concede the rest at
no significant cost to ourselves.@
That slogan also pre-supposes an infinite number of small, individual, unrelated
(i.e., Aretail@)
interactions with customersCand it
still works in that context. But if we lose sight of the very different
realities of relations among constituents in a complex system, an open promise
to accommodate unilateral demands is doomed to fail. In AIS systems, we are
beginning to recognize that their (marvelous) complexity exposes us to
management tests that are unprecedented in our experience. Still, the nub of the
customization issue remains reasonably clear: good management in order to reduce
customization to the truly necessary minimum and implementation of alternative
strategies for the rest of the wish list. TW
The Edutech Report is a monthly publication of Magna Publications
The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.