At least since the work of Les Gasser (1986:216), the act of working-around (or jury rigging) and the resulting workaround (or kluge) has been good fodder for Science and Technology Studies (STS). In the transition from building administrative software in-house to purchasing packaged software solutions from private market vendors, the workaround has received renewed attention by scholars. And rightly so. These are pressing matters given the widespread use of packaged software, the near irreversibility of implementations projects once initiated, and the reported high probably of dissatisfaction following installation.
Workarounds are commonly employed to localize, maintain, and extend software programs, especially when it is necessary to coax occasionally suboptimal implementations into functioning properly as the systems age. Still, workarounds have their limitations; they grow brittle over time, but are crucial for freeing users from restrictive or incomplete systems. Research on packaged software, however, challenges the notion that systems are still worked-around. Designers of packaged software anticipate user modifications. Embedded and increasingly inter-organizational actors now determine when a work endeavor is or is not defined as a workaround. Pollock (2005), examining a case of package software being implemented in a university setting, shows how the boundary between users and designers is relationally dynamic rather than static. This is clear when, for instance, local users share code with software designers hired by vendors, but also when designers distance their responsibility over specific user problems by categorizing some problems as local (rather than the general concern of numerous implementing organizations) (505, 503). Because packaged software appears to presuppose that adopting organizations will participate in the design process by modifying the software for local use, Pollock seems to have updated Gasser’s (1986) notion of working-around. Pollock calls into question Gasser’s (1986:216) original formulation, specifically, that working-around implies “intentionally using computing in ways for which it was not designed,” given that the tools to work-around are already embedded-within packaged software.
Research also suggests that workarounds are not as freeing as previous literature indicates. Modifications do not only free local users from the constraints of technology; they also create tensions inside and between organizations. For example, modifications that are difficult and therefore slow to establish create tension between employees and their supervisors (Pollock 2005:507). Likewise, some modifications generate conflict between support desk operators and local programmers concerning who is responsible for coaxing the packaged software into operation (506). Also examining packaged software in higher education, Kitto and Higgins (2010), through the lens of governmentality, show how a university wrested control over their newly adopted ERP by modifying it. Surprisingly, once modified, the resulting system did not appear to create renewed autonomy for employees. Instead, control over the system simply shifted from the monolithic vendor to a more local supervisor charged with maintaining jurisdiction over the host of new modifications.
In the move from homegrown to packaged software in higher education, traditional interpretations of the workaround seem to be transforming, and with it, I imagine, the precursors of workarounds – the “gaps” in system operations that workarounds necessarily bridge … although there is scant research on where these workarounds come from.