I give up! Five factors that contribute to the abandonment of information management strategies

Authors


  • This material is based upon work supported by the National Science Foundation under Grant No. 0534386.

Abstract

In this paper, we present initial findings from a six-month study involving qualitative interviews on the topic of project-related personal information management. Specifically, we report on the emergent theme of information management strategy abandonment - that is, what factors in particular might cause people to give up on their systems for managing documents, calendars, email, and other sorts of project information. In exploring the recurrence of this theme throughout the interview data, five factors emerged as particularly compelling and frequently-cited reasons for system abandonment: (1) visibility, (2) integration, (3) co-adoption, (4) scalability, and (5) return on investment. We describe each of these factors in turn, using examples from the interviews for illustration. These findings, though preliminary in nature, provide a starting point for understanding why systems fail and how future systems might be designed to improve their success rate.

Few of us are completely satisfied with the way we manage the information that helps us perform our daily activities. Our email inboxes overflow, the papers pile up on our desks, and our various calendars and to-do lists become neglected or overwhelmingly complicated. But this does not stop us from trying. We look for better ways; practices that make information management easier, so that we can get on with our lives. Along the way, we often leave a trail of abandoned systems behind us, or weave back and forth between new systems and old.

The systems we each develop involve a combination of existing information management tools and strategies for their use. Boardman and Sasse (2004) observed that people often maintain several distinct systems depending upon the information form involved. Participants in their study tended to be most organized for electronic documents and other files, for which organization most frequently took the form of folders correlated with particular projects. Folders were less commonly used to organize web bookmarks, and, when used, they more typically reflected a topic area rather than a specific project.

Consistent with the idea that individuals organize their information by topic and project is Kwasnik's (1989) observation that expected use or intended purpose is often a primary consideration in the development of an organization system. Documents, then, may be organized for use on a current project whereas web references (when the trouble is taken to save these) may more likely be organized by topic, as part of a reference collection intended for repeated use. Information is also organized according to activity level or frequency of use. For example, Cole (1982) observed that people tend to divide their information broadly into three categories - action information (to be processed in the next few days), project information (relevant to current projects) and archival information.

But what about the success of different systems of information management? Bruce, Jones and Dumais (2004) discussed results of a survey in which the same strategies of organization were listed by different respondents as both having “worked” and “not worked” with the wisdom of hindsight. For example, respondents cited variations of both “leave everything in the inbox” and “clean the inbox regularly” as strategies that had worked or proven unworkable (“too cluttered!” or “waste of time”).i

Yet, this research does not tell us why one system worked and another did not. So we arrive at the guiding question of this paper: What factors determine whether a system of information management - and its associated strategies and organizational schemes - will succeed or fail? The question has broad practical significance. Many of us have embraced a system of information management only to abandon it later - often after considerable time and frustration. Are there ways we might increase a system's chances of success, or more quickly foresee its ultimate failure?

Some preliminary answers to these questions emerged over the course of an interview-based study of individuals' personal information practices. The interviews in this study did not focus specifically or intentionally on the abandonment of information management strategies, but the phenomenon nonetheless arose as a persistent theme throughout participants' responses.

Methods

Semi-structured interviews were conducted with twenty-two participants (6 male, 16 female) ages 20-60, from February to August of 2007. Of these participants, fourteen were students (1 undergraduate, 4 masters, 9 doctoral), two were executive assistants, and the remaining six were, respectively, a librarian, an environmental scientist, a college administrator, a student services manager, and a literacy coach. All but four participants were interviewed in their place of work; participants who carried all their project-related information with them were interviewed at the university library.

Fourteen participants were interviewed a single time; the other six completed a second, follow-up interview. During the first interview, each participant was asked to describe the “information space” of a medium-term (6-8 week) project. To explore that space, the researcher asked to see the paper documents, electronic files, email, and web references being used for the selected project. The researcher posed questions to better understand the “how” and “why” behind the various uses and organizations of project-related information. More holistic questions were also asked about the participants' satisfaction with their organization systems, and how those systems might be improved. Follow-up interviews explored any changes that had occurred in the participants' organization strategies in the intervening weeks between sessions. All interviews were audio recorded and transcribed.

In the analysis phase, the interview transcripts were coded using a constant comparative technique to elicit overarching themes. In this way, emergent themes, including the theme of system abandonment highlighted here, were identified and drawn out based on the participants' actual utterances. Particular phrases that correlated strongly with a coding of strategy abandonment included “I used to” and “I tried to.”

Results

Of the 22 participants interviewed, fourteen reported experiencing at least one situation in which they had abandoned an information management strategy. The participant who reported the greatest number, a doctoral student, described seven such situations that had arisen in his work. In total, 33 separate examples of strategy abandonment were noted for all interview participants. Abandoned strategies included:

  • Using particular software or online tools for planning or analysis (8)
  • Collaborative planning and version-tracking systems (5)
  • Filing systems for electronic information (4)
  • Systems for keeping track of research literature (3)
  • Keeping to-do lists in particular formats (3)
  • Using to-do lists in general (3)
  • Specific naming practices for electronic files (2)
  • Filing systems for paper information (2)
  • Tagging systems for email or other files (2)
  • Systematically tracking work hours (1)

Clearly, this is a broad range of strategies, and in practice, those strategies entailed an equally broad range of time and effort expenditure prior to abandonment. In some cases - particularly with electronic filing, nomenclature, and versioning systems - the systems had been in use for the duration of one or more extended projects before the participants were pushed to change. In others - particularly involving the use of specific tools for planning or analysis - the systems were abandoned quite soon after their initial adoption.

Nonetheless, five common threads ran through these divergent types of abandonment situations, emerging to a greater or lesser degree depending on the particular circumstances. In describing the frustrations or failures that led them to change systems, participants typically alluded to one or more of the following five factors:

  • 1. Visibility
  • 2. Integration
  • 3. Co-Adoption
  • 4. Scalability
  • 5. Return on Investment

Inwhat follows, we will explicate each of these factors, and provide some illustrative - though by no means exhaustive - examples from the interviews themselves.

1. Visibility

Visibility emerged as an issue influencing the abandonment of newer systems more often than older ones - particularly new information management software, to-do lists, and filing systems. If the participant couldn't keep the system in their peripheral vision, they reported, they would forget it was there, and thus wouldn't go back and use it again.

A few participant comments made particularly clear reference to the visibility issue. For example, a doctoral student cited visibility as the reason he stopped using a particular system for keeping track of important articles: “I stopped looking at this material so I never went back to it. So I actually forgot that I had some of these documents.” [GC-115] An executive assistant had a similar issue with Outlook's task list, commenting:

“I need something that is constantly visual to me and these paper pads just happen to be the thing. Because even though I have the task pad on Outlook, it's not constantly open.” [MS-122]

And finally, a master's student noted that calendaring in general had been a problem for her due to visibility problems:

“It's a lot harder to keep track of…things that I want to do even if I really want to do it. I'm not keeping track of it. I'm not looking - you know I'll write it down but I might not look into it. I'm not looking at my calendar every single day.” [JS-105]

2. Integration

Integration issues tended to be interlinked with the visibility problems described above. When a system did not interconnect well with other systems the participant already had in place, that system would fall into disuse in much the same way as a system with low visibility. Indeed, in some cases, the reason for a system's low visibility could be directly traced to poor integration with other systems.

One doctoral student described a case in which improved integration helped make a previously problematic system more helpful for his purposes, partially by ameliorating the visibility problem:

“Google calendar did not originally work well for me. … Eventually I started - it may have been one of the e-mails I got. I remember earlier on when I started using it more I got an e-mail that said you know, “Click this to add this to the calendar.” And that made it easy to add something to the calendar and eventually I needed to keep track of you know like a series of days or somebody's birthday or something like that. The calendar was right there. I mean I was checking my email anyway - so I went there and put it in there.” [GC-115]

3. Co-Adoption

When multiple individuals must work as a group, it often becomes necessary for those involved to develop and share a system for versioning, scheduling, or information-sharing. However, these ad hoc systems sometimes broke down for the same reason that special-purpose applications sometimes fail (e.g., Grudin, 1988) - levels of work among group members were disproportionate and levels adoption were uneven. For example, one part of the group would implement a particular strategy, but that strategy would eventually fail because another part of the group failed to use it. This type of failure occurred with particular frequency in situations where the success of a strategy depended on an employer adopting an employee-implemented system.

In one such instance, an administrative assistant expressed frustration with her manager's apparent indifference to her attempts to reorganize his outbox for paperwork, noting:

“it's in his office and he knows about it, but I don't know if he's following it or not

So, I don't know if that system is working for him. It seems like there have been a lot of things I've tried to do for him that haven't really sort of taken off.” [JL-119]

Similarly, a doctoral student described how his attempt to set up a shared online filing system for his research assistantship failed because none of his team members ever used it. As he put it,

“It's one of those deals where at a certain point you realize you are throwing effort after nothing. And you stop doing it. … It means nothing to other people so if I'm not doing it for myself, why bother.” [EM-109]

4. Scalability

Scalability appeared especially influential in the abandonment of more entrenched systems. In eight of the cases reported, systems put into place to manage a certain kind of information failed to adequately handle greater complexity following project growth and progress, increased collaboration, or new life or work circumstances.

Participants offered examples of scalability problems taken from a range of project contexts. An architect explained why he stopped using notebooks to handle his to-do lists in terms of increased life complexity:

“at [an earlier] point in my life it was very easy to organize my entire life in one notebook because I focused on personal stuff. … The problem now is that what is my life and what is the business is very confused.” [Gb-113]

A literacy coach similarly cited low scalability in the abandonment of a shared file-naming system, concluding that, “it kind of got too much … the coding system started to look like Algebra in front. So, it's just - so we quit doing that.” [CM-108] And finally, a student services administrator noted that the lack of scalability in certain software made him stop using it in more complex situations:

“I find that Microsoft Project is good for when I'm working on one particular project. But when you've got 4 or 6 different things all going at the same time, it's just too much - too many timelines to be looking at just to make it useful for me.” [ML-112]

5. Return on Investment

Participants seemed especially likely to abandon systems that were too complicated or that took too much effort to learn, regardless of the duration of use prior to abandonment. In particular, when participants perceived that an information management strategy would require more effort to implement and use than it would ultimately save them through its affordances, they would judge the system “not worthwhile” and give it up.

Indeed, participants frequently framed comments about this type of situation in terms that explicitly or implicitly invoked cost-benefit tradeoffs. For example, the doctoral student who had problems with the lack of integration provided by early versions of Google Calendar went on to note:

“if it's not convenient I don't see a direct return. … If it's too much of a pain to input stuff, why do it right? Maybe that's kind of what I saw with the labels? There was not really much of a return on an investment right?” [GC-115]

And similarly, an executive assistant abandoned the use of a piece of software called “Projects” because, as she put it, “it's almost more maintenance and takes more time to actually upkeep than it does to do it.” [JL-119].

Discussion

This paper has presented five factors that play into individuals' decisions to abandon information management strategies. While visibility, integration, co-adoption, scalability, and return on investment undoubtedly are not the only reasons for strategy abandonment, they formed strong themes in the explanations for abandonment offered by the participants in our study. Thus, at the very least, these factors provide points of departure for thinking about ways that the design of new systems might encourage and enable the average user's perseverance in using a particular system, by enhancing any or all of these system characteristics.

We return to the question posed at the outset of this paper. Are there ways we might increase a system's chances of success, or more quickly foresee its ultimate failure? When good systems fail it is frequently for want of visibility, integration or lack of co-adoption. Clearly, these factors interrelate. A system increases in visibility, for example, through integrations that increase its opportunity for use and its number of incidental appearances in the user's workday. Similarly, a synergistic relationship often holds between the factors of visibility and co-adoption: visibility may increase the chances that a system will be used by the members of a group. In turn, adoption of a system by some members of a group can increase its visibility, if only through happenstance mention of the system in conversation or chance encounters in which one member of the group is seen using the system.

Co-adoption is a “swing” factor that, together with the factors of scalability and return on investment, might help us better to foresee the ultimate failure of a system, and thereby save time and effort by either abandoning the system sooner or by correcting more quickly for its limitations. If a system's success depends upon widespread adoption among group members, but the group has little chance of achieving it, then better to know at the outset before investing time and energy on a doomed effort. Similarly, if the system can't scale with time and increasing use or if the numbers ultimately “don't add up” in a calculus of cost vs. benefit, then better to know this at the outset.

We have all thrown up our hands in dismay with some system at some time. And, in the rush of our lives, we've surely missed many opportunities to use better systems. Each is a kind of failure - a failure to “cut one's losses” with established systems that are no longer working or to take up new systems that may ultimately repay the costs of their adoption many times over. Understanding the reasons behind these failures represents a first step towards finding ways to make them a less pervasive fact of life.

  1. 1

    Many other excellent studies relate to the question of how people organize their information. For a review, see Jones (2007, ch. 5).

Ancillary