Technology Implementation >> The Power of TWO

Click here to receive your FREE subscription to Campus Technology

Home > Technology Implementation >> The Power of TWO

Features

Technology Implementation >> The Power of TWO

5/27/2005

By Matt Villano

Divide tasks evenly. The whole notion of a “partnership” implies that both entities— school and vendor—will work together for a greater good. This d'esn’t mean relying on the vendor for everything; instead, it means working to divvy up the task list so both parties can pitch in.

Get it in writing. Once you’ve communicated goals and distributed tasks, it’s important to put everything into a contract so responsibilities are clear from the get-go. Chances are that once you draw it up, you won’t need to refer to this document again. But if there’s trouble with a contract, you’re covered.

Benchmark. No partnership works without consistent checks and balances. Set performance goals and reevaluate as you reach them. This kind of benchmarking motivates both parties, and keeps everyone abreast of how the project is progressing over time.

Celebrate success. Once the project is finished, don’t ignore the accomplishment: Announce the milestone to the community at large and “eternalize” the effort with a case study or recap. Reward participants with a dinner or day off. Remember: The best way to keep people interested is to reward them when they merit the favor.

“In a best-case scenario, we were hoping for something we could use that would also serve as a revenue generator for us,” he says now, looking back. “There was some risk involved because nobody had ever done this before, but we figured we had nothing to lose.”

In reality, though, the partnership wasn’t so cut-and-dry. As things got going, the code that the university programmers contributed worked well, but the code that SCT wrote to accompany it was problematic. Convincing SCT programmers that the problems resided on their side of the code, says Mendola, was a challenge; in the end, it took some weeks, and the situation was resolved only when both parties met for two days in an off-site “summit” to iron out the problem. At that meeting, Mendola and his colleagues at UI presented SCT programmers with more than 200 pages of documentation addressing details of the problem. Understandably, SCT programmers were skeptical of the claims, and laboriously walked through the documentation before they realized university’s argument had merit. Correcting those problems took months.

Finally, the integration project was finished at the end of 2001. Not only did the parties come together to iron out their differences, but they also seized the opportunity to donate the resulting code to a new organization they created for the purposes of promulgating the benefits of standards-based enterprise application integration: the OpenEAI Foundation (www.openeai.org). Yet, OpenEAI was only one positive by-product of the UI/SCT alliance; though Illinois paid $250,000 for thecode from SunGard SCT, today Mendola says the school will earn up to twice that amount in royalties from its vendor partner as a result of the alliance.

“They sell products and we get money,” Mendola concludes. “Everybody wins. That sounds like a good partnership to me.”