Share this Page

IT and Advancement >> Family Feud

By Bennett Voyles

03/31/05

>> Do your IT and Advancement areas have an ‘uneasy’
relationship? Here’s what’s behind the friction— and how you
can minimize it.

Talk to CIOs and advancement officers about how their respective departments
get along, and their first response is often a nervous, knowing chuckle; the
kind people normally reserve for some perennial family dispute—Oh, well,
you know what he’s like

The tension, if it d'es indeed exist, is not due simply to the language gap
between techies and non-techies. After all, campus computer analysts are used
to contending with many clients who don’t speak their language. Nor is
it just because their roles give them fundamentally different views of the world,
with the computer experts looking to build ever-stronger walls to keep their
systems safe, even as Advancement tries to build more bridges to the outside
world.

Perhaps the intensity of the dispute may stem from the fact that Advancement
is what business people call a profit center. Although other departments may
not like a system they’ve been issued, development officers find it easier
to make a dollars-and-cents case that their lack of the ideal system is going
to have a direct financial impact on the university. To make the case for centralization
even more difficult—from the CIO’s point of view—is the fact
that advancement professionals aren’t necessarily dependent on Central
IT to fund their IT needs. After all, they do know a thing or two about raising
money.

While two decades of steady IT development should have cooled some of these
disputes, the IT/Advancement relationship may actually have grown even more
fragile on many campuses in recent years. One of the biggest battles: the recent
IT department push for Advancement to join a single, integrated, campuswide
IT (or ERP) system.

From the IT department vantage point, centralization just makes sense. Mandating
a single, campuswide system minimizes the costs of training and maintenance,
and makes shifting data from one department to another a relatively simple matter.
But, from the point of view of the Advancement office, the benefits aren’t
always so clear. A centralized platform frequently locks the fundraising team
into the ERP system’s fundraising module, which often has only limited
functionality.

“There’s a real frustration among a lot of college advancement
officers,” says Diane Crane, director of the Information Services practice
at Bentz Whaley Flessner (www.bwt.com),
fundraising consultants based in Washington DC and Minneapolis. “They
feel that the college actually pays a high cost for that integrated system,
and the cost is a lack of Advancement productivity, because they’re working
with an inefficient, less-than-robust advancement system.” The ERP system’s
customer relationship management (CRM) tools also typically lack the sophistication
advancement officers see in standalone packages.
Says Ed Barboni, an IT consultant for the Council of Independent Colleges (www.cic.edu),
“If they’re really into customer relationship management, and they’re
really into the Web, with communities, etcetera none of these packages
will meet their needs.”

There are other potential “costs,” as well. Fred Waugh, a marketing
VP for Convio (www.convio.com),
supplier of CRM software to nonprofit companies, argues that with centralized
systems, additional, non-software benefits may be lost. With standalone advancement/development
software products, training and consulting provided by the vendor often help
the office gain understanding of new or additional approaches to community development
and fundraising.

However, some advancement officers may be overlooking the advantages of being
part of a centralized system.

At Bucknell University (PA), Shelby Radcliffe McClintock,
associate campaign director and director of Prospect Research and Management,
says that campus IT gave her office the choice of using or not using the campuswide
system. After a long period of consideration, she says, her office decided,
on balance, that they would be better off centralized. Data entry, for instance,
would be much easier with a consolidated system, and new parent names could
be ported directly from the Registrar, to her office.

Should Advancement jump on the campuswide system?

PRO

CON

YES. IT will need to write less code for each department.

NO. Typically, single solutions provide less functionality for Advancement
than a dedicated fundraising package.

YES. Training is cheaper.

NO. With dedicated solutions, training can add more value, because
the vendors are development experts.

YES. A single system is easier to maintain.

NO. Unless there are dedicated IT staff, Advancement’s needs
are easier to overlook.

YES. A single system creates new opportunities for data-sharing.

NO. With campuswide solutions, new risks may arise over privacy issues.

YES. Easier data entry means names are entered once and the job is
done.

Centralization has also offered new opportunities to beef up alumni research,
according to McClintock. “I was excited by a number of things: I would,
for instance, be able to figure out who had lived in the same freshman hall,”
she says. “From a fundraising perspective, if you’re trying to get
in the door with a potential donor, it’s nice to know who they know, and
you can look at what their student activities and major had been.”

Yet, since joining the campus ERP system six months earlier, even the generally
positive McClintock concedes it will take six to 18 months for her office to
create the same caliber of reports they could pull from their older, independent
system before they joined the campuswide system. Her staffers first have to
learn the system, then learn to work around functional limitations that analysts
discovered since going live with the system. Then too, they’ll have to
rewrite thousands of reports they had developed for the old system. McClintock
sees a lot of work ahead.

Barboni reports that at other schools, the combination of limited centralized
software capabilities and limited staff support sometimes incline Advancement
offices to fight to maintain their independence. “Those are usually the
two reasons that development officers say, ‘Give me my own, and leave
me alone,’” he explains.

Yet, Barboni adds that the major problems with ERP systems, in general, often
reside not only with the software, but with the underlying business processes.
Frequently, he says, colleges will simply automate their existing processes
rather than re-engineer systems and processes together, which is vital when
a campus converts to a single system.

“I’ve been on over a hundred campuses, and one campus will be
screaming about how inadequate its ERP system is, while on another, everyone
is as happy as a clam,” Barboni says. “It’s all about business
process design; it’s not about the software. It’s really not the
sophistication of the software; it’s the sophistication of the minds.”

Avoiding Conflicts

Though it may seem that such a dispute could lead only to a winner-take-all
solution, some well-heeled schools with strong IT development people are able
to combine the best of both worlds by writing code that bridges the gap between
the specialized standalone software and the campuswide system. Smaller institutions,
however, don’t feel they have that luxury. Limited funds and limited programming
staff lead CIOs to believe they must choose between standalone development and
integrated ERP systems, according to Charlie Hunsaker, president of RI Arlington
(riarlington.com), a Pennsylvania
IT consulting firm to nonprofits. He argues that many details often need to
be worked out over time. “I’ve worked with schools that have said,
flat-out: ‘We’re going with an ERP approach because we don’t
have the resources to support more than one vendor’s product. We don’t
have time to build interfaces ” But, he points out, introducing
an ERP system to save labor costs isn’t a good idea, because systems are
never quite as integrated as billed; extensive work is always required to complete
the job, and many details need to be worked out over time. For example, he posits,
what if the Advancement office sees that alumni Mary Smith and John Jones just
got married, so it changes their campus records to reflect that marriage, but
Mary Smith happens to be an employee of the university? “When the campuswide
system changes her to Mary Jones, she d'esn’t get her paycheck, because
Advancement was heads up and right on time.”

Still, says Hunsaker, institutions that say they want an ERP system because
they don’t have time for anything else, “are the institutions that
are going to have a problem, whichever path they choose.”

Roberts Wesleyan College (NY) is one institution that has
decided to stick with standalone systems, in Advancement and elsewhere. “It’s
very difficult for one entity to write a system that will work for Admissions,
Registration, Student Billing, Accounting, the Advancement office, and all the
individual needs involved,” says CIO Pradeep “Peter” Saxena.
Instead, Saxena has let each department choose its own system. He gave department
leaders some clear parameters—such as being able to run on a Microsoft
server platform, client compatibility with Windows XP, and good data import
and export utilities—and then let them decide. Once individual departments
choose the software they like, he says, he finds that, typically, the product
meets 90 to 95 percent of department need.

For schools that choose standalone systems, experts advise, it’s essential
to build in the data integration as you go. “If you want the ideal of
the integration,” says the CIC’s Barboni, “but you’re
still going to go with the separate packages, then build the two-way communications
in the data models and the database from the get-go. Otherwise, you’re
going to pay for it big-time, down the road.”

Crane at Bentz Whaley Flessner argues that while integrating standalone systems
was difficult in the ’90s, it’s become much easier over the past
three or four years. “A lot of college information officers still are
thinking in that mentality from the ’90s: More systems equals more problems,
challenges, and costs. Too much of the decision-making is based on that kind
of mentality, as opposed to really assessing the return on investment,”
she says.

Yet, creating such interdepartmental data links is not that hard, according
to Barboni. “It’s pretty straightforward if—and it’s
a big if—you have somebody who really understands databases. But those
individuals don’t come cheap. The smaller the school is, the less likely
it is that it’s going to have that kind of a person, and if you don’t
have that individual, it can be a nightmare.”

Build a Network

Ironically, whether the challenge is training the advancement team to use an
ERP system, or coping with its requests for more Web or e-mail support, the
key to better relationships seems to be building a strong network of stakeholders.
IT and development pros alike say that clarity of communication is key.

“The biggest problem is communication,” says Saxena. “People
don’t communicate their needs or sit down and talk about what they’re
trying to do and what you’re trying to do. Because of these barriers,
people think that they’re on opposite sides of the wall when they’re
truly on the same side of it.” Language itself hinders communication,
even after 20 years of technology on campus, adds Saxena: “The technical
folks tend to talk about database fields, system attributes, and code values.
And the fundraisers say, ‘What’s the fundraising issue? What’s
the cost to raise a dollar? How do we compare last year’s numbers to this
year’s?’”

Even when both sides do understand each other, it’s sometimes difficult
to clarify the important issues. Often, Hunsaker says, miscommunication occurs
because of the different level of detail that each side works in: “Development
is saying, ‘What can the system do for me? How can it help me do my work?
And IT is saying, what do you want it to do?’”

In some cases, trust is the real issue. McClintock at Bucknell says that at
some schools, prospect researchers in Advancement offices are still having trouble
using their databases, and that can be because “there are still researchers
out there who are not allowed to write queries for their own database,”
she explains. “These are people who actually are capable of building predictive
models for their databases, and yet they don’t have permission to do it.”

Hunsaker advises: “If somebody in IT can talk the business issues, and
somebody on the fundraising side can talk the IT issues, then communication
becomes improved. But you need to find the middle ground between the technical
and the business to be able to address these issues.”

The campuses where Advancement and IT are happiest may be those where the advancement
officers treat the IT staff with the same kind of care they take in cultivating
a major donor. Jeffrey Donah'e, senior director of Advancement Communications
at Georgetown University’s (DC) Alumni office, is one
believer in building good relationships with IT. But don’t forget the
human side of the relationship, he advises. “Persistence certainly pays,”
he says, “but persistence and lunch really pay.”

Still, as useful as schmoozing is, in the end, it’s only useful if it
clarifies the roles and responsibilities of each camp. According to Jon Thorson,
senior director of Development Resources at the American Red Cross in Washington,
DC, and a former advancement officer at Princeton University
(NJ), “In IT, like any other support function, people are not going to
deliver well against requirements that aren’t defined. We have the responsibility
to define the requirements and make them really clear.”

Integrating Central IT and Advancement technical staff can also help smooth
differences. McClintock says that the Bucknell Development office has two IT
people and a dedicated person from central IT working in their office. Having
this kind of dedicated staff is important, McClintock says, in order to make
sure that Advancement’s requests have some urgency.

And at the University of Washington, the Office of Development
and Alumni Relations takes relationship-building between IT and Development
even further, says Shawn Drew, the director of Information there: The office
grows its own Central Computing contacts. The alumni office’s Technology
department typically hires relatively inexperienced programmers, gives them
some experience and training, and eventually, when there’s an opening
in the Central Computing department, encourages them to move on to more challenging
positions in that office. As a result, UW Development’s lead contact with
Central Computing is a former technical person from its own office. When he
started at Central Computing, Drew says, “This individual already knew
all about UW Development—who we are, what we do, what our priorities are,
and the reasons why we do the things we do.”

Next Skirmish: E-Mail

In recent years, e-mail in particular has attracted the attention of advancement
officers for the same reasons it has interested all kinds of marketing professionals:
The medium is cheap and easy to use for tailored messages. Such immediate connections
may even encourage more generous giving: At Georgetown, average levels of participation
in the university’s latest annual giving campaign were about $100 more
for alumni for whom the school had e-mail addresses, according to Donah'e. Small
wonder, then, that some advancement officers are no longer content to let the
IT department handle all their e-mail concerns.

And according to John Murphy, Higher Ed Market Development manager for Convio,
“A lot of colleges recognize that e-mail presents such a specialized and
important, mission-critical set of functions that, politically, advancement
offices are asserting ownership over them so they can execute [e-mail solicitation]
correctly.”

In fact, Georgetown is one school where the IT/Advancement boundaries have
been duly tested in recent years. Donah'e says that installing a new “e-mail
forever” system (a lifetime e-mail forwarding service for alumni) created
a number of challenging new issues for the university’s central IT and
Alumni Relations departments to negotiate.

One issue they faced: how to handle lost IDs and passwords. IT wanted a highly
secure system that required alums to fax in identification before being allowed
to reset their passwords. The alumni team on the other hand, wanted to keep
the process as simple as possible, says Donah'e. “We’re in alumni
relations. Our whole thing is making it easy for the consumer.”

Advancement didn’t want to thwart giving. “We want people crawling
all over the site,” he says, but adds that IT explained that the password
system needed to be secure because e-mail accounts could be left open to invasion
and identity theft. An audit trail was needed, to show why a password change
had been made.

Over time, the two offices have been able to work out a compromise around registration
and password issues—but such compromises take time and effort, says Donah'e.
“It’s easy to creep back into respective corners: ‘I’m
the data integrity person and the data will be protected,’ and, ‘I’m
the alumni relations person and I want alumni to be able to change passwords
on a whim.’ But, you’ve got to get people understanding what the
other side needs and how the other side d'es business,” he says.

Since the password negotiations, says Donah'e, the Alumni office seems to have
developed a deeper appreciation of the value of the division of labor, when
it comes to IT needs. “We’re good at a lot of stuff, but keeping
up with the latest trends in data security isn’t at the top of our list,”
he admits. “But that’s what turns on CIOs, and that’s what
protects our alumni.”