You’re editing a database, or maybe downloading an online document, or formatting a Web page when a dialogue box highlighted by a large red “X” suddenly leaps open: “This program has performed an illegal operation and will be shut down,” it tersely informs. An illegal operation? Hoping for some clarity and guidance, you select “details” and a new message reads: “[The application] caused an invalid page fault in module MFC42.DLL at 18f: 6c37ed6c, etc., etc.” No wiser than before, and resigned to losing anything not already saved, you reluctantly “close.”
Undaunted (“I ain’t afraid of no ghost”), you try re-loading the application. And, sure enough, you’re back at square one. Holding your breath, you make your first tentative keystrokes or highlight a selection with the mouse—only to be ambushed again: “If the problem persists contact the program vendor,” the box recommends. (Expletives deleted.)
You reboot, hoping this will chase the demons away. Three, four, more vain attempts, each punctuated by the keyboard mantra: CTRL+ALT+DELETE. The morning’s shot; you’re convinced that your computer is truly possessed. Who y’ gonna call?
Popularly called “tech support,” the term encompasses the range of activities essential to keeping hardware and software assets in good working order—from installing and integrating to repairing and upgrading. The prospect of battling “long-leggety beasties and things that go bump in the night” can get downright overwhelming in a cyber realm inhabited by macro viruses, incompatible software applications and Internet files that take forever to download. And, for most of us, “if there’s something weird and it don’t look good,” we’re calling tech support.
In the 1984 movie Ghostbusters, actors Dan Aykroyd, Ernie Hudson, Bill Murray and Harold Ramis portrayed the A-Team of the paranormal—zapping, trapping and warehousing the eternally disembodied. The jargon-laden paranormal shtick of Aykroyd and Ramis was a central plot device setting up the bewildering and single-minded devastation wrought by the team’s Proton blasters—and the ensuing mayhem of by-standers scrambling out of the line of fire. As the smoke cleared, our heroes would calmly collect their fee and depart.
For a cyber-exorcism, the notion of tech support frequently evokes a similar set of images: armed with arcane knowledge, a predilection toward certain kinds of solutions and loads of inexplicable paraphernalia, The Expert arrives. Asked to describe the problem, we are immediately relegated to an Awed By-stander. The Expert hovers over our equipment muttering indecipherable incantations, with appropriately enigmatic gestures. If he (usually) even notices that we’re still in the room, he might deign to explain what he’s doing and why. Sometimes we catch ourselves nodding as if we had a clue. When the fog lifts, we discover that he’s also collected his fee and left.
Admittedly, the situation described is extreme, but a number of recent studies suggest that most nonprofits tend to regard tech related problems as annoyances to be fixed—attending either to the squeaky wheel or the dire emergency, sometimes repeatedly. Typically, most of us will assume the fault is in the hardware or software. Such an orientation contributes to a characteristically episodic, reactive and piecemeal approach to solving technology problems—with an accompanying dependence on someone else’s expert wisdom.
An alternative perspective, where problem-solving becomes an opportunity for organizational learning, is emerging from discussions among nonprofit managers and IT professionals. Rather than leading with the question, “what got broke,” this view considers the broader interplay of hardware, software and human-ware within the organization, asking instead “what happened, how did it happen, how broad are the effects, and is there a pattern?” According to proponents of this model, systematic and ongoing assessment of needs, organizational capacity and opportunities will increase productivity, while reducing costs and dependence on outsiders as well.1
As a practical matter, who you call for help depends on the severity of the haunting and the resources readily available to the organization. For many problems, tech support might be as close as the pull-down menu offered in most software applications, the experiences of co-workers, or the vendor’s dial-in or online service.
But who tracks and responds to tech-related issues? Who identifies staff training needs, evaluates system capabilities and decides on system upgrades? Who manages service contracts with technology vendors? And how do you decide?
Marc Osten, a frequent contributor to this magazine, maintains that tech-related problems will inevitably fall somewhere along a continuum ranging from simple to complex—the greater the complexity, the more sophisticated the technical expertise, the higher the expense. Similarly, tech-support needs can be grouped under the broad categories of user application-related support, hardware support, database support, and network administration (reflecting a similar ratio of complexity to cost).
The new thinking views tech support as a strategic consideration demanding a deliberate, “whole systems” 2 approach. “Tech-support is a factor in the long-term sustainability of your technology assets,” Osten explains. “The issue isn’t so much finding the right expert, but beginning to think of technology problems as opportunities for acquiring useful skills and knowledge for the entire organization—a deceptively subtle shift in perspective.” Indeed, according to Osten, the bulk of tech support needs can usually be addressed relatively inexpensively in-house. (See Tips box.)
Emphasis on the creation of organizational knowledge and capacity—over merely oiling the squeaky-wheel-of-the-moment—reaffirms the user’s central role in shaping technology-related decisions and restores a measure of control and predictability to expenditures. Over time, simply tracking and sharing the tech-related problems, questions and solutions arising from actual use will see requests for outside expertise diminish as the knowledge-base of the organization expands.
“Reducing dependence on outside vendors is not necessarily a hallmark of gaining greater control of your IT systems,” says Dan Scharfman of Baird Associates,3 an IT consulting group in eastern Massachusetts. Noting that few nonprofit managers have specific experience or expertise in this area, hiring and supervision can become equally problematic. “Several nonprofits I work with have described their in-house IT staff as loose cannons, fitting in poorly with the rest of staff and fostering a marked degree of dependence on that individual.”
Sign up for our free newsletters
Subscribe to NPQ's newsletters to have our top stories delivered directly to your inbox.
By signing up, you agree to our privacy policy and terms of use, and to receive messages from NPQ and our partners.
“In- or outsourced, managers can’t afford to duck their responsibility for defining the tasks, roles and expectations of the people providing technical expertise to their organization,” Scharfman insists. “It doesn’t really matter whether the people filling this role are called staff or consultant.”
Baltimore-based Neighborhood Design Center is a nonprofit providing pro bono technical assistance to grassroots neighborhood revitalization projects. Mark Cameron, NDC’s executive director, has experienced the up and downsides of outsourced tech support services. “Our network consultants have proven very helpful with timely assistance and guidance for maintaining and upgrading our systems,” Cameron observes. “But it hasn’t been the same story for the person providing technical support for our database.”
Cameron inherited both contractors, but he’s clear that the organization’s dependence on the database specialist is untenable for the long run. In fact, the contrast between the attitudes of the network contractor, whose attentiveness to the needs of the organization has produced cost-savings in many areas, and the generally unresponsive, unapproachable and often unavailable database consultant underscores the distinction between the two perspectives. “A good tech support person is one who really understands what you do and what your needs are,” Cameron concludes. “The relationship is the thing.”
The NDC, currently involved in a strategic technology planning process, is intent on replacing the database person while also creating the in-house function of accidental technologist—someone who can troubleshoot, assist other staff and knows enough to serve as liaison to technology vendors and outside consultants.4
The application of this inquiry-based approach in one mid-sized, New England-based nonprofit is an interesting case in point. With a complement of 32 program and administrative staff (including an in-house technology manager), networked computers at each workstation, and an extensive database, the organization is also enjoying a growing Internet presence through its Web site and periodic e-newsletter. The annual technology budget is over $125,000 (roughly 2.5 percent of operating), a level of investment demonstrating a keen appreciation for its strategic value to core mission and programs.
Accordingly, technology planning is decentralized, vested in a cross-staff team responsible for developing internal policies and procedures. Its primary function is linking technology decisions to broader strategic considerations affecting the entire organization. The “tech team” conducts periodic staff audits of current use and projected technology needs, coordinates staff training, manages outsourced technical support services, and monitors equipment purchases and retirement. In a very real sense, the team serves as the organization’s central repository of new knowledge in this functional area.
Wayne, the organization’s in-house technology manager, is “content expert” for the team. Barred from actually chairing the group, Wayne assumes the daily hands-on responsibility for trouble-shooting problems, developing staff skills and working with technology vendors. In another life, he was a grassroots tenant organizer; and followed the path of the accidental techie to his current vocation. The empowering orientation of doing with, rather than doing for, is something Wayne naturally brings to his tech support efforts. Responding to staff needs and concerns, he routinely applies information generated by incident logs and technology audits to the design of “brown-bag” mini-trainings and regular “tech-tips.”
These simple innovations are steadily moving his organization away from the “it’s broke, fix it” mentality, toward an active commitment to collective inquiry and systematic experimentation.
For example, a recent flurry of intranet exchanges sharing opinions on the best method for producing PDF documents was not even initiated by Wayne—although it did subsequently inform the decision to purchase a software upgrade with this functionality. Management decisions on equipment or software purchases and upgrades, staff training and engaging consulting services are similarly informed by data generated within the organization.
“Technical knowledge is obviously important,” he admits. “But tech support has to be responsive and respectful to the technology user as well—and that means having some people skills and a plan.”
“Bustin’ makes you feel so good…”
1. See the Nonprofit Quarterly’s ongoing coverage of strategic technology, beginning in August 2000 and continuing in April, July, and Winter of 2001.
2. The “whole systems” approach applied to technical support issues begins with a definition of support needs, developing a strategy, implementing and monitoring the effort, considering issues of long-term sustainability, and, finally, evaluating effectiveness. Each step in the process feeds and informs the next; evaluation creates new knowledge, often leading to a deepening or refinement of the organization’s understanding of its needs.
3. Baird Associates offers a number
of useful tips on how to look at improving your nonprofit’s IT capability. (www.bairdassociates.com/BairdBytes)
4. See also “How To Support Your Computer and Internet Systems,” an online document produced by Coyote Communications. (www.coyotecom.com/database/support.html)
by Marc Osten
1. Assign one “point person” in the organization who knows where technical support issues flow.
2. Develop a list of your basic technical support needs.
3. Write down next to each “need” the person or vendor who services those needs.
4. Identify the five most frequent, simple technical support calls staff make and develop a “tip sheet” to empower staff to handle those problems by themselves.
5. Post the tip sheet at every workstation.
6. Hold an in-house mini-training on each of these simple technical support solutions.
7. Develop a log to track technical support calls to identify future “tip sheet” topics and trainings.
8. Develop a simple form that vendors need to fill out detailing what they did while on-site.
9. Identify, support and appoint “accidental techies” on staff to help handle simple internal tech support needs.
10. Every year try to turn over a quarter to a third of your workstations to reduce technical support costs.
Source: Summit Collaborative (www.summitcollaborative.com)
