IT and Advancement >> Family Feud -- Campus Technology

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.	NO. Universal access creates new challenges for maintaining data integrity.

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.”