James H. Sweeney is a big-picture guy. When you have a title like American Dental Association Group Associate Executive Director, Business, Technical, and Meetings Services, you have to be.
Back in 1993, when it became clear that the ADA's 1988-vintage, mainframe-driven management system was headed to that big hex-dump in the sky, the ADA actually did what every organization is supposed to do when shopping for new technology: Sweeney pulled together a team, and team members sat back and thought hard about what it was going to take to get their organization safely into the next century. Especially since, at the time, the next century was only seven years away.
Five years later, in 1998, Sweeney and team are still moving toward their goal. They've had some wins and some frustrations, but they're a lot wiser about implementing high-tech solutions than they used to be. This is the story of the lessons they learned in trying to make their big-picture vision real.
Lesson One: Getting the Big Idea The first thing to understand about the ADA is that it is what Sweeney calls "a tripartite association." This means that to belong to the Chicago-based ADA, a dentist must also belong to both a local and a state dental society.
While the concept of linkage at the national, state, and local levels was well understood, it wasn't particularly well executed. Information transfer among organizations was cumbersome. Priorities were different. For example, local organizations performed referrals, while the national organization did nothing of the kind.
The team's big idea was to use the installation of a new computer system to improve information transfer at all levels. They decided the new computer system had to serve everybody--all 50 state societies and about 350 local groups.
An essential part of having the big picture, of course, is getting others to buy into it. Knowing that each one of these 400 or so groups was independent and protective of its identity, the ADA formed the Software Needs Identification Team, or SNIT. This team was a vehicle for bringing users from the state and local societies to Chicago to consider the project. The goal was to come to a consensus about what features the new software should have that could be created within a reasonable time frame and budget. SNIT team members were asked to rank features in order of priority, labeling each one as a "must have," "nice to have," "we can do without this on the first pass," or "we won't ever use this."
As this process unfolded, Sweeney and his team learned that it was absolutely essential to ask users what tasks they did that they wanted the software to replicate, rather than asking them what they wanted the software to do.
"We had to be careful to define very clearly what the elements of the systems would be, so that their expectations were not greater, or different, from what we delivered," says Sweeney.
There was diplomacy involved, too. For example, while the ADA planned to give away the system software to the state and local users, it made it clear that the individual societies would be responsible for whatever infrastructure and hardware upgrades were needed, including new PCs, modems, and data transmission lines. (The ADA itself committed to a major overhaul of its computing capabilities.) Ever mindful of local organization sensitivities, the ADA made a point of offering the software to the state and local societies, but not compelling its use.
Lesson Two: Picking a Technology Partner Also participating in the SNIT meetings was the software vendor charged, so to speak, with actually painting the ADA's big picture. Picking a technology partner was a three-year process, according to Sweeney. After many auditions, the ADA signed on with MEI Software Systems Inc. Headquartered in Reston, Va., MEI has been developing association software since 1975.
MEI already had a "basic system that was in the neighborhood of what we were looking for," says Susan Katz, assistant executive director, conference and meeting services, ADA. Most important, the company "understood the tripartite concept better than anybody," Sweeney stresses. Plus, he adds, the MEI staff is "young, interested, and aggressive."
Certainly Glenn Hickman, director of software architecture for MEI, and the initial ADA project manager, became well-versed in the tripartite's complexities.
"We found the three different parties had different priorities," he says. "One of the things that was interesting was coming up with a first set of modules that would reflect a compromise among the needs of each of the three parties in the tripartite. The software [development project] is the unifying factor, getting them all to work together, tying them in together."
The ADA decided to purchase 10 modules in all, including membership and meeting modules, customized for the ADA's specific needs. The first to be completed, the membership system, was being tested at the ADA and two state associations at press time.
Lesson Three: Slower Is Faster Originally, the ADA planned to launch the new meeting module at the October 1998 annual meeting. Now the plan is to implement the module first for a small meeting in March 1999, then use it for the 1999 annual meeting. What happened?
For one thing, the meeting module cannot be implemented without the membership module in place. And the membership module, with its data sync innovation (see "What's a TAMS?", page 34), was quite complicated to develop, says Hickman.
"This wasn't a perfect project," acknowledges Hickman. "If we could do it all over again, we probably would have insisted on a little more time to develop each module. The dates were not really realistic. We recognize why things need to happen quickly, but associations should take our experience to heart, especially when it comes to how long it is going to take. We can get too ambitious. Software vendors always try to make it happen, but sometimes that is not the best course. Sometimes, slower is faster."
Sweeney concedes that the time frame was unrealistic. "We underestimated the resources and time we needed to develop that part of the program," he says. And the longer it takes, the more technology advances, necessitating more revisions, because, says Sweeney, "we see better ways to do business."
Another factor, points out Peter W. Kauffman, MEI chairman, is that the meeting module, "is every bit as complex as the membership module," because it has to be flexible enough to handle constant change. "Everybody signs up for events," he says. "Then [members] say, 'I can't go. I'm sending so-and-so to substitute for me,' or, 'Now that I'm bringing ten people, can I get that discount?' That is the reality of what meetings people deal with every day. What is seemingly simple on the surface, as you peel it, becomes a challenge."
Lesson Four: It Takes More Than Talk If he had it to do again, says Sweeney, "We would spend more time doing some relationship-building between ADA and MEI development staff. You really need the synergy. I think at the beginning of this process they didn't have empathy for what [ADA] was doing."
Katz agrees, noting that the ADA changed its approach along the way. "We learned through the process," she says. ADA meeting staff have visited MEI, she says, "stayed with their programmers, watched them work, talked about how they function. It gave the staff here another level of confidence about the people who were working on the project."
Despite the inevitable communication mishaps, both sides feel the relationship has been a positive experience. "One thing that has helped this project is the willingness of people on both sides to work with one another," says Hickman. "Everyone has maintained a good attitude even when there are disappointments. We've been able to come to realistic agreements, there hasn't been any finger-pointing. It's more of a teamwork type thing, where you encounter obstacles and figure out to how overcome them together.
The results of this team effort on the meetings side of the organization will be seen fully next year, when the ADA uses its new meeting management software to organize the 1999 annual conference, which will be held October 3 to 6 at the Hawaii Convention Center in Honolulu.
Lesson Five: The Sky's the Limit Plans for upgrading the network are in the works, even though the complete software package is yet to be launched. The ADA decided not to make the first version Web-enabled because the team thought members were not ready. Surveys conducted in 1996 indicated that only 23 percent of members had Internet access. Only 7,000 members have accessed the members-only home page. But those figures are growing, and the next step will be to make the system Web-enabled.
That won't be difficult, says Kauffman, now that the foundation is in place. "We built all the controls in there," he says, "so implementation of Web registration, [for example], will be very straightforward."
The process of converting to a new computer system is long and complicated, but it is a transition that all associations and businesses must go through to be successful, asserts Katz. "Software is changing so quickly none of us can be complacent about what is out there. How we do business is changing dramatically. The sooner you accept the change and grow with it, the better off you are going to be."
While a five-year process may represent centuries in cyber-years, the ADA has only just begun its journey. "We will constantly continue to upgrade the infrastructure, the hardware, and the software," Sweeney declares. "I would say the sky's the limit."