charting time: timelines as temporal boundary objects
TRANSCRIPT
Charting time: Timelines as temporal boundary objects
Elaine K. Yakura
Michigan State UniversitySchool of Labor and Industrial Relations
436 South Kedzie HallEast Lansing, MI 48824-1032
(517) [email protected]
November 2001
ACKNOWLEDGEMENTSI am grateful for the constructive comments and inspired suggestions by the Guest Coeditor, Joel
Baum, and the three anonymous reviewers.
2
Charting time: Timelines as temporal boundary objects
ABSTRACT
This paper investigates the use of visual artifacts to represent time. Timelines (or Gantt
charts) are widely used for scheduling, budgeting, and project management, and are woven into
the fabric of organizational life. Timelines embody objectivist, monotemporal assumptions about
time, yet allow organizational and occupational subgroups with different assumptions to
negotiate and manage time, prospectively and retrospectively. Timelines thus function as
temporal boundary objects, visual representations of time that are both interpretively flexible and
robust.
abstract word count: 75
3
Charting time: Timelines as temporal boundary objects
The Gantt chart, because of its presentation of facts in their relation
to time, is the most notable contribution to the art of management
made in this generation. (Clark, 1922: 3)
Devices for measuring time, such as clocks and calendars, were developed centuries ago
(Thompson, 1967; Borst 1993). By contrast, devices for charting time in organizations are a
relatively recent invention. Henry Gantt, an industrial engineering consultant, developed the first
widely-used time charts for the U.S. Ordnance department during World War I (Rathe, 1961).
Gantt charts, by using straight lines on a grid, compare what was done with what was planned
over time. These “simple” charts (Clark, 1922: 138) allow the viewer to manage the project:
“[w]ithout charts an executive is utterly helpless” (Trabold, 1922: 149). Gantt charts, however,
did not highlight interdependence among tasks, which became more critical as projects became
larger and more complex. In the late 1950’s, the PERT (Project Evaluation and Review
Technique) chart was introduced to coordinate the activities of 250 contractors and over 9,000
subcontractors during of the Polaris nuclear submarine project (Levin & Kirkpatrick, 1966;
Marks, Taylor, Schoen, & Susbauer, 1966; Sapolsky, 1972).
In this paper, I use the term "timeline" to refer to a graphical representation of a set of
temporal units punctuated by “tasks,” "events," or "milestones." Today, these timelines (also
known as “Gantt charts,” “milestone charts,” “PERT charts,” and “project timelines”) have
become so ubiquitous that it is easy to overlook their significance. Nearly every significant
project or proposal has a timeline, and they have a clear value as a practical tool for project
management (Mulvaney, 1969). Yet as Yates (1989) and Star (1999) have noted, mundane and
even boring artifacts of business—such as filing systems—can shape our assumptions and
4
practices. Timelines are especially interesting artifacts because they seem to render time, the
ultimate abstraction (Adam, 1990), visible and concrete.
I argue that timelines function as temporal boundary objects that make time concrete and
negotiable for various groups of participants. Unlike other boundary objects that have been
previously identified, such as engineering design drawings (Henderson, 1999), or maps (Star &
Griesemer, 1989), timelines embody the key elements of narrative: a beginning, a middle, an
ending, and a focal topic (Ochs, 1997). Of these elements, the ending is the most important part:
timelines allow participants to envision the ending of an otherwise open-ended story. The
narrative quality of temporal boundary objects distinguishes them from other organizational
artifacts, and explains some of their unique properties as tools for temporal coordination.
Timelines are theoretically interesting because they depend on the assumption that time
can be represented in standardized, invariable, context-free units (Adam, 1990). This
decontextualized representation reflects what Nandhakumar and Jones (2001: 195) call a
“mechanistic” or monotemporal model of time. In contrast, real organizational settings are more
likely to be pluritemporal (Nowotny, 1992), due to the multiplicity of cultural and occupational
groups, each with its own assumptions about time (Dubinskas, 1988a). This contrast motivates
my main research question: how do these essentially monotemporal artifacts function in the
pluritemporal context of real organizations?
To address such a question, we need detailed, descriptive data on how are timelines are
used in practice. As Nandhakumar and Jones (2001: 195) and others have argued, we need to
develop “a more nuanced understanding of how time is actually organized in work practices.”
We know timelines are widely used, but we do not know much about how they are used. The
literature on timelines is largely prescriptive (e.g., Rathe, 1961; Mulvaney, 1969), and as Hassard
5
(1996) notes, there are few descriptive or theoretical analyses of time in work organizations. By
providing ethnographic data on the use of timelines, this paper helps address this gap.
This paper examines timelines in a context where their use is especially prominent: the
implementation of large information systems. Timelines are crucial in managing these complex
projects and coordinating the activities of consultants, clients, users, and other participants.
Because of their complexity, these projects provide a rich source of data about the use of
timelines in practice. This context is also interesting because information technology consultants
represent a large and growing sector of the workforce (Bloomfield & Danieli, 1995). Like many
knowledge workers (Reich, 1991), their work is difficult to measure or define (Yakura, 2001).
Thus, for this occupational community, timelines have tremendous practical value as a measure
of work, progress, and performance.
The paper makes various contributions to the literature on time and organizations. First,
it provides a qualitative treatment of time in organizations, illustrating how various subgroups in
an organization use timelines as a nexus for understanding and negotiating their differing
interpretations of time. This type of exploration of the meanings and experiences of time in
organizations has been sorely lacking in the literature (Hassard, 1996; Nandhakumar & Jones,
2001). As researchers, we employ a wide variety of techniques for measuring and modeling time
(e.g., clock time, event time, logarithmic time, etc; Abbott, 1990). Yet these measures are rather
abstract; in actual practice, people use pictures. Since we can't feel or hear time, we have
devised elaborate ways of depicting it. Second, the paper extends Star and Griesemer’s (1989)
concept of a boundary object. Timelines, as temporal boundary objects, not only serve as a
nexus for interpretation and negotiation by different groups, but also “fill in” an ending
(successful project completion) to an inherently uncertain endeavor.
6
The following section presents a brief review of the literature on time in organizations.
But since this material will be well represented elsewhere in this special issue, I focus more
attention on the construction and interpretation of this artifact. This practice of charting time is
inherently visual, a fact which contributes to its taken-for-granted nature (after all, “seeing is
believing”). By drawing on research on time in other occupational communities (Bucciarelli,
1994; Strauss, Schatzman, Ehrlich, Bucher, & Sabshin, 1964; Zerubavel, 1979), we can begin to
understand the operation of this important category of artifacts. Then, using examples selected
from fieldwork at a consulting firm, I illustrate the use of timelines and their unique role in
consulting engagements. Timelines functions as a kind of placeholder—a way for participants to
negotiate and translate between and among their diverse understandings of time.
PLURITEMPORALISM IN ORGANIZATIONS
There is a large and growing literature on time in organizations (Adam, 1995) which
draws on a variety of disciplines (Bergmann, 1992; Nowotny 1992). Indeed, time provides an
important backdrop for a wide range of organization theories (Zaheer, Albert & Zaheer, 1999).
Much of our research on time is quantitative, which Hassard (1996: 585) notes “mostly fail[s] to
capture the complexity of industrial temporality.” Thus, Hassard and others (Adams, 1990; Lee
& Liebenau, 1999; Nandhakumar & Jones, 2001) argue for more qualitative research that might
better capture the experience of time in work organizations.
Qualitative studies of time have documented what Nowotny (1992: 424) calls
“pluritemporalism,” the side-by-side existence of many different types of time, socially
constructed out of experiences by those living it (Elias, 1992; Giddens, 1984; Gurvitch, 1964).
This "nascent paradigm" (Hassard, 1996) focuses on ways in which time is interpreted or
assigned meaning. A well known example of this type of research is Roy's (1959) study of
7
factory work, where he describes how workers differentiated break times within the work day
(such as “fish” time and “banana” time) to achieve more control and satisfaction.
Other groups at work also “make” time, and Dubinskas and his colleagues provide
detailed portraits of the ways engineers (Bucciarelli, 1988), managers (Dubinskas, 1988b),
physicists (Traweek, 1988), and radiologists (Barley, 1988), constructed and interpreted time.
Whether these groups are termed occupational subcultures (Trice, 1993) or occupational
communities (Van Maanen & Barley, 1984), time is constructed and interpreted differently in
different cultural groups. This is not unexpected, since time is key to culture in anthropology;
indeed, Hall (1989: 4-5) argues that “time and culture are inseparable in certain circumstances.”
Like the factory workers' "banana time," many occupational groups develop a shared perspective
on time. As Sharron (1982: 78) noted, groups frequently develop a specialized "subcultural
lingo" that "enables action in concert time between professionals who are not otherwise
associated with one another.”
Hospital settings, where various professional/occupational groups work in concert to
accomplish their goals, also demonstrate this phenomenon. Strauss and his colleagues (1964:
164) argue that understandings negotiated among these hospital subcultures have a temporal
aspect, either explicit or implicit: "[a]s one listens to agreements being made in the hospital, or
watches understandings being established, he becomes aware that a specific termination period,
or date line, is often written into the agreement." Psychiatrists, social workers, nurses, and aides
negotiated temporal understandings about patient treatments. Zerubavel (1979; 1981) also
examines what he termed "temporal orders" in a hospital, and illustrates how these temporal
orders both unified and differentiated the various occupational groups. For example, even across
different groups, there was a sense of concert in time: "in the hospital people can often tell the
8
time without referring to a clock, by simply observing what goes on around them" (Zerubavel,
1981: 16). Yet different subcultures were also differentiated by temporal boundaries: the
higher-status doctors had more flexibly defined temporal boundaries than lower-status nurses.
Thus, I take pluritemporalism as a starting point; interpretations of time differ where
diverse subcultures and occupational communities co-exist. This diversity gives rise to the
practical problem of how to sustain collective action and negotiate temporal arrangements. After
all, schedules must be set, tasks must be coordinated, and performance must be measured. Time
is integral to deadlines, budgets and other critical measures of success and performance (Yakura,
2001), and the interpretation of time has a great deal of practical significance for all participants
in a complicated project. One way in which organizational participants achieve a kind of
practical “monotemporalism” while retaining the diversity of interpretations and interests is
through the use of timelines.
TIMELINES: ARTIFACTS FOR CHARTING TIME
Timelines are a visual means of displaying the actual vs. planned progress of a project
over time. To explain the unique role that these familiar artifacts play in organizations, I build
on the general concept of a boundary object (Star & Griesemer, 1989). Then, I describe the
specific features that distinguish timelines as temporal boundary objects and the basic functions
of timelines as set forth by Hassard (1991). These concepts form the basis for the analysis of the
ethnographic data in the remainder of the paper.
Timelines as Boundary Objects
Henderson (1991; 1999) argues that all engineering diagrams can be viewed as a type of
boundary object (Star, 1991; Star & Griesemer, 1989). For an artifact to serve as a boundary
object, is must be “…both plastic enough to adapt to local needs and constraints of the several
9
parties employing them, yet robust enough to maintain a common identity across sites" (Star &
Griesemer, 1989: 393). Engineering boundary objects (Henderson, 1999: 200) represent
different ways of knowing "that are capable of being read on different levels by different groups
involved with the design and its final product." Different engineering disciplines (e.g., electrical,
mechanical, manufacturing, and so on) focus on different aspects of the representation and “fill
in” the interpretation that is important to them. For this reason, these distinctive visual artifacts
can be useful tools for understanding different subcultures (Goodwin, 1994).
Timelines are an incredibly effective vessel for "filling in;" as visual artifacts, timelines
are more easily processed than other forms of communication (Barry, 1997: 279). They
capitalize on the "obviousness" provided by our visual senses, as well as our ability to supply
narrative structure to static images. For example, advertising uses images and pictures (rather
than text or numbers, for example) to convey information in the most quickly and easily
understood form. "Advertising images thus act as condensed cultural symbols, visually reduced
statements that suggest a story line that targeted consumers complete in their own
imaginations..." Barry, 1997: 279). The idea that "every picture tells a story" is more than just an
old aphorism; appropriately constructed still images "take on narrative significance as well,
implying action immediately preceding and following the frame, as in a well-drawn comic strip"
(Barry, 1997: 149).
Thus, unlike the boundary objects that have been reported in other studies (e.g., Star and
Griesemer, 1989; Henderson, 1999), timelines have special narrative qualities. Because
timelines portray a series of events in time with a clear beginning, middle and end, they satisfy
the minimal conditions for narrative, conveying the relationship of events in time (Bruner, 1990;
Ochs, 1997). The narrative logic of the timeline suggests that once you start, you will finish; the
10
tasks and milestones are portrayed as flowing linearly and progressively. In this way, timelines
set the expectation of a definite, predictable conclusion. They are intended to be the roadmap by
which participants navigate through a complex set of interdependent tasks (Mulvaney, 1969).
Timelines are helpful devices for prospective sensemaking (Weick, 1995); we use the chart to fill
in our understanding of what will happen, even when the future is uncertain and unpredictable
(Bucciarelli, 1994).
It is the narrative quality of the timelines that distinguishes them as temporal boundary
objects. Timelines portray “facts in their relation to time” (Clark, 1922: 3), which a core aspect
of any narrative (Ochs, 1997). Even this skeletal narrative structure provides a powerful visual
metaphor: the passage of milestones, along the journey towards an endpoint or conclusion.
Everyone who has worked on a systems project knows that the deadlines so clearly printed on
the crisp, clean charts are rarely met (Brooks, 1975). This aspect of timelines arises, in part,
because timelines are used prospectively. As Bucciarelli (1994) notes, there is nearly always a
gap between the “ideal” and the “reality” of a design engineering project. While the image of the
timeline reifies and provides a sense of concreteness, each participant in a project is free to
interpret the timeline from his or her own perspective and "fill in" the gaps in different ways.
This combination of concreteness and flexibility is critical to the operation of the timeline as a
boundary object for different subcultures or communities.
Basic Functions of Timelines
Hassard (1991: 116) identifies three temporal issues that emerge in organizations: “(1)
the need for schedules, i.e., for reliable predictions of the points in time at which specific actions
will occur, (2) the need for synchronization, i.e., for temporal coordination among functionally
segmented parts and activities, and (3) the need for time allocation, i.e., for distributing time so
11
that activities will consume it in the most effective and rational way." Timelines, a means of
measuring the actual vs. planned progress of an activity over time, fulfill all three of these
temporal needs. Research studies on the engineering community and their work illustrate how
they schedule, synchronize and allocate time in projects. Bucciarelli (1994: 50), in examining
engineering design projects at three different engineering firms, describes how the design
engineers use "milestone charts" to visualize time and measure progress. Time in these projects
is used both as a resource and a reference. As a resource, time is available to these engineers to
be used and spent by the project team, and moved or allocated from one specific task to another,
such that a task's duration can shrink or stretch. In this sense, it is analogous to Hassard’s time
allocation category. As a reference, time moves by at a uniform, steady pace, independent of any
particular project task or activity. This enables Bucciarelli’s engineers to schedule time, as in
Hassard’s first category. Thus, the milestone charts created by these engineers allow for time to
be visualized both as a resource and as a reference, and fulfills the needs for time scheduling as
well as allocation.
These basic functional categories identified by Hassard and Bucciarelli illustrate why
timelines are viewed as crucial by the managers of large projects. These categories are described
in one form or another in every practical guide to timelines since the early 1920s (e.g., Clark,
1922; Mulvaney, 1969). As we shall see, these issues were everyday concerns for information
technology consultants and their clients.
While these categories make perfect sense, they are based on mechanistic or
monocultural assumptions, and obscure the fact that timelines are not used by a single,
homogeneous cultural group. Rather, in most situations, timelines are used by several different
groups that assign different meanings to the temporal artifacts. Thus, time, which seems so
12
concrete and objective in the timelines, is not necessarily interpreted the same way by each
group. As described above, qualitative research methods are required to uncover these different
interpretations, and theoretically-sensitive concepts (such as "boundary object") must take these
pluritemporal interpretations into account. In the sections that follow, I will examine the way that
information technology consultants, their managers, and their clients used and interpreted
timelines to fill in and negotiate the details of a typical, troublesome project.
RESEARCH METHOD
The data presented here were collected during long term participant observation of
information technology consulting firms. Participant observation was necessary because the
research focused on the meanings and interpretations of the project participants (Spradley, 1980).
Without observing and participating in daily activities of the consulting engagement, it would be
impossible to understand the significance of timelines (or any other phenomenon) from the
perspective of the participants. While this would be a poor method for generating statistical
results, it is essential to address the topic of this paper.
The consulting firm ("ITCF”) was headquartered in a large U.S. city in the Midwest, but
most of the project activity I observed took place at the client site in a mid-sized city in a
neighboring state. My role was that of a full-time participant observer (Spradley, 1980; Agar,
1996), working with consultants as part of the project team, talking to both consultants and
clients about the consulting work and context, and collecting written materials pertinent to
consulting work and the client project. I had negotiated access with the management at the
branch office where the project was located. My fieldwork at this site began with the first team
meeting after the project “kickoff” meeting, and ended when only one consultant (the project
manager) remained on site to finish the project (approximately 15 months from the kickoff
13
meeting). I visited the site three to four times a week, depending on the activities at the client
site.
My role as a participant observer and researcher was explained to everyone with whom I
had contact (consultants and clients alike), and I agreed to disguise all individual and
organizational names using pseudonyms. I was not paid for my services, but was reimbursed by
the firm for my expenses (which were minimal) in exchange for assisting the project team to the
limits of my ability while I was on site. Thus, in many respects, my day-to-day activities were
very similar to those of junior-level consultants. In this case, I assisted them with documentation
and other administrative tasks.
I recorded my observations of information technology consultants in daily fieldnotes
(Sanjek, 1990). Analyzing these fieldnotes involved several iterative steps associated with
grounded theory (Strauss, 1987; Strauss & Corbin, 1990), including devising and attaching
categories to the data in the fieldnotes, making connections between and among categories,
revising the categories, and re-coding the fieldnotes. From the very first day in the field, it was
clear that timelines were a central artifact for IT projects, as well as of particular concern to the
various groups involved in IT projects. I made a point of collecting timelines and tracking very
closely how they were used. I also coded all references in my fieldnotes to timelines and to
items in the timelines (including timeline task definitions, subcultural interpretations, deadlines,
etc.). The data presented here come from the ITCF project engagement, and include selections
from the collection of ITCF project timelines. In light of my research questions, I have chosen to
present this material as a "realist tale" (Van Maanen, 1988).
14
SITE DESCRIPTION
The Information Technology Consulting Context
Information technology consulting is a context that requires a lot of "filling in." Some
types of services are relatively well-understood, such as fast-food services or certain professional
services (e.g., legal services in uncontested divorce proceedings, or routine medical checkups).
But consulting is a type of knowledge-based service that can be characterized as indeterminate
(Boreham, 1983; Bowen & Schneider, 1988; Mills, 1986), especially as compared to physical
goods and products. The intangibility of a service means that it cannot be fully specified in
advance. A consulting engagement will always specify a “deliverable,” something that the
consultant promises to deliver to the client by the end of the engagement. The deliverable may
be a functioning retail banking demand deposit account system, or a report consisting of several
pages of presentation overheads. By giving the intangible service a tangible product, the
consultant provides the client a familiar artifact as an outcome of the engagement.
The Consulting Firm
ITCF provided consulting services related to applications software and project
management. Founded 25 years ago by its Chief Executive Officer, the firm employed
approximately 1200 people at 25 branches around the country. The activities of the ITCF were
overseen by an executive committee, which consisted of the head of human resources and the
Chief Information Officer, as well as the CEO and the director of each of the three geographic
areas. The number of branches varied from five to twelve for the three areas of the country, and
the branch managers reported to the director for their geographic area.
The managers at each branch oversaw the work of the branch, which included hiring and
firing of consultants, deciding who would work at which client site for how long, and billing the
15
clients for services rendered. There were several levels of managers, and the more senior
managers tended to handle the more problematic client or employment problems. Junior
managers regularly visited their assigned client sites to talk to the consultants and clients about
their concerns. In this organization, most of the managers had “risen” from the ranks of the
consultants, although most consultants preferred technical tasks, and sought to avoid the
administrative burdens that accompanied the managerial role. The managers at ITCF were
distinguished by their years of experience, rather than their formal degree training; few held
MBA or other advanced degrees.
The consultants actually did the work at client sites. Their job titles, which ranged from
associate programmer (someone who recently completed their undergraduate education, with
little or no experience) to project manager, generally determined their billing rates. ITCF hired
programmers and analysts, who either worked on consulting teams or as “standalones" at client
sites.
The Client
The ITCF project client was Midwest Electric (MWE), a large public utility in the
Midwest. For the ITCF consultants, MWE represented a “typical” public utility: the organization
had many levels, and decisions seemed to take a long time as they moved up the levels. The
pace of decision-making was demonstrated by the signing of the ITCF/MWE contract for the
project engagement. Once the decision to hire ITCF was made, the ITCF management expected
that the contract would be signed and the work begun in a few weeks, as set forth in the proposal.
However, the approval of the contract took several months, much longer than anyone at ITCF
anticipated. Differences in expectations around the contract approval process were an early
indicator of the different time orientations of ITCF and MWE. For members of the consulting
16
firm, time was money. Consultants were judged by the number of hours they “billed” to a client,
so that time not working on a client project was “wasted.” For members of the public utility, time
did not have a similar “billable” value.
There was another feature of MWE that seemed confusing to the ITCF consultants. In
their other client organizations, consultants identified with their peers in the internal systems
organization, since they had the same technical orientation and “thought” alike. In fact, the
project manager and other consultants prided themselves on their ability to “get along” with
systems professionals at client organizations. In the case of MWE, however, several of the key
MWE internal systems managers (including the MWE project manager) were trained in
accounting and not computer science. To the ITCF team, these MWE systems managers were
unfamiliar with simple technical aspects of their own systems. At MWE, the people the ITCF
team considered the “real technical people” reported to these accountants.
The Engagement: Modifying OATS
MWE sought a consulting firm to modify and install a software package it had purchased
for collection of overdue accounts (Overdue Account Tracking System, or “OATS”). The MWE
billing department, in conjunction with the MWE internal systems department, contacted four
consulting companies, including ITCF, and asked them to submit a proposal for the work. ITCF
was selected for the project, and their original project costs were estimated at $700,000, with a
duration of six months.
Because the engagement was large, and because it was the first one for this particular
large client, it had high visibility at that ITCF branch and at headquarters. Memos emphasizing
the need for delivering "a quality product while beating our project targets" circulated among the
team members and branch management. This was particularly difficult—for this project, they
17
had agreed to do a "fixed price" contract. This meant that no matter how many hours of
consulting time the implementation required, the client would pay a predetermined amount. This
is almost never a desirable constraint for a consulting firm. For example, problems might arise
with the project for a number of reasons outside their (or the client's) control; this might require
expending much more time and/or resources for the consulting firm to complete the project. Yet,
because this was a new client, and represented diversification in terms of client industry, ITCF
agreed to this condition of the project. As one ITCF manager said, “once we get our foot in the
door, we can easily get follow-on work.” One of the branch managers explained that since this
was a fixed price project, "This project will be managed and tracked very closely, especially in
the beginning." Yet, despite this constraint, he urged, "Let's make this project an ITCF
showcase!"
Timelines in the OATS engagement. Kevin, the ITCF project manager, was responsible
for managing the OATS project. In principle, the project followed a standard systems
development process. First, the consultants would confirm that the OATS system was installed
and running on the client’s systems (the consultants referred to this as “baseline testing”).
Second, they would prepare detailed specifications for the necessary changes, which the client
would review and approve before using these specifications as the basis for writing code to
modify the OATS system. Next, they would test the changes and submit them for approval by
the client. Finally, they would train the users and roll out the new system for use.
As project manager, Kevin produced the weekly progress reports for the engagement,
which consisted of several parts. The first part was called “Project Memorandum,” and was
divided into three sections: (1) “Tasks” (a brief listing of the tasks the consulting team had
worked on that week); (2) “Plans” (another brief listing of the tasks planned for the next week);
18
and (3) “Issues” (a slightly more detailed list which described any anticipated issues or problems.
Appended to this memorandum were various timeline and supporting documents. The first was
a “high-level” timeline (see figure 1), showing the overview of the tasks for the entire project,
with interdependent tasks and timelines indicating the estimated duration of the task (e.g., "code
and test") displayed across the page. While technically a PERT chart, the participants generally
referred to it as a "timeline." In figure 1, “pm” refers to “project manager”; “sa” refers to
“systems analyst”, and so on; the “+” indicates others are also involved. This view had a single
milestone (“M”) at the completion of the project, but the detailed sheets contained milestones for
each major phase of the project and its deliverables.
Insert figure 1 about here
This sample timeline was selected to convey the “look and feel” of a typical project
timeline in a limited space. In actuality, the “detailed” versions of the timelines were over eight
pages. Even the “high-level” view grew in length and complexity as the project progressed; by
the second month, it ran to nearly three pages. There were several more “detail” sheets
accompanying the timeline: (1) a full listing of project tasks; (2) the product delivery schedule;
(3) the budget summary, and (4) the total of the actual hours spent by each member of the
consulting team versus the projected. The detailed project task list the scheduled completion
date, actual completion date, the name of the responsible consultant, and the name of the client
who was responsible for accepting the work. The last two sets also included information on the
billable hours budgeted for each task and the amounts invoiced. Of course, for this fixed price
project, these last two sets were only be used to calculate “shortfall.”
An overview of the engagement. The project started with the "kickoff meeting," which
was a largely ceremonial meeting between the client and the consulting firm. Most of those who
19
had working on negotiating the contract attended this kickoff meeting. Timelines were a focal
point of meeting, and were seen as a vehicle for informing the client about the status of the
project, including progress to date and future plans. Because MWE took months (rather than
weeks) to sign the contract, the milestones and deadlines from the original ITCF documents had
to be revised. Thus, like many such projects, it was late even before it started. Everyone
expressed concern over the “slippage” in the dates, but agreed that it was not ITCF’s fault.
Almost immediately, however, the project was beset by a variety of delays and conflicts that
forced nearly constant revision of the timeline. The very first task, the “OATS initial test” could
not proceed as planned because critical files were missing and could not be found. Later, a key
member of the ITCF team because seriously ill and had to be hospitalized. The MWE approval
process introduced unexpected delays and confrontations. Other work on the OATS system, to
be performed by the MWE systems department (not by ITCF) introduced additional constraints
and delays. Ultimately, ten additional people were brought in to work at the site. The project,
which had originally been scheduled for completion in six months, took well over a year and a
half. In the sections that follow, I analyze in greater detail aspects of the function of timelines in
this complex project.
DATA AND ANALYSIS
In the sections that follow, I will use data from the OATS engagement to develop three
interconnected themes: (1) the basic functions of timelines as identified by Hassard (1991); (2)
the existence of multiple, divergent interpretations of time; and (3) the role of timelines as a
locus for negotiation among groups. This analysis leads to the main contribution of this paper,
which concerns the special qualities of timelines as temporal boundary objects.
20
Basic Functions of Timelines
Recall that Hassard (1996) identifies three key temporal issues in organizations:
scheduling, allocation and synchronization. Examples of how the timeline served each of these
functions in the OATS engagement follow.
Scheduling. The use of timelines for scheduling was most prominent, in the
straightforward sense that the timeline embodied a schedule for the project. When some aspect
of the project changed (e.g., the start date), all the subsequent dates had to be adjusted
accordingly and rescheduled. In the OATS engagement, there were two especially notable
examples of circumstances that prompted the use of timelines for scheduling: missing files and
an unexpected illness.
As part of the contract, MWE had warranted that the original OATS system, which would
undergo modification by the consulting team, had been installed and was ready for use by the
consulting team. From the first day they were on site, however, Kevin and Jack were stumped
by a problem they called “missing files.” Some of these files were sample data files that had
been created and provided by the software vendor specifically for the purpose of testing the
system. Other files involved modules of the software that the consulting team thought the client
had purchased. The software vendor, located in another part of the country, assured the
consultants that all of the files should have been installed. The software, however, had not been
installed by the OATS vendor. Rather, it had been done by MWE, who had warranted that the
OATS system was in working order.
Another unanticipated event involved a serious illness. About one month after the project
had begun, the first systems analyst assigned to the project (Jack) had a heart attack, and it was
apparent that Jack would spend at least several months recuperating. Part of Jack’s task was to
21
find the "missing" files, and while he had documented this search, he had done so weekly (as
required). Jack’s heart attack had occurred before he completed his weekly report, creating a
time "void" in the sense that one week's worth of his work had been lost. This was exacerbated
by the fact that one of the key MWE systems administrators had been on vacation, and had not
been available to work on this issue. Assigning a new systems analyst to the client site and
bringing them up to speed on the client system took some additional time, of course, and
required that all subsequent project tasks be rescheduled accordingly.
Allocation. The timeline was instrumental in resource allocation decisions. As the
project fell further behind, it became apparent that the consulting team would need to work
overtime and bring in additional consulting staff. During the second month of the project,
additional analysts were added to the project team as planned. As the months went by, it became
very apparent that they would not meet their first big milestone at the end of the third month of
the project. At a consulting firm meeting, attended by Kevin (the ITCF project manager) and
three branch managers, they discussed the project deadlines.
Kevin: The lines [communication lines which connected the various parts of the system
they were working on, located in different geographic areas] were very bad on
Friday.
Manager 1: Did you lose time?
Kevin: Well, the system is up today.
Manager 2: So the plan is we bring on 3 more programmers on Monday. What's the
status? [Peering at the timeline:] We haven't gotten those sign-offs yet?
Kevin: Nope.
Manager 3: Kevin, how many of those [systems] modules do you have?
22
Kevin: [Looking at the task report:] Eight.
Manager 2: Done? Typed? Diagrams attached? All the signatures attached? All
ready?
Kevin: W-e-e-e-e-e-l-l-l-l-l-l-l…
Manager 1: In the best case, you can barely hit the date.
Kevin: Well, if we let it slip another week [points at the chart], then we can have Charlie
[whom they all believed was an excellent programmer, but who would not be
available until the next week since he was busy finishing up a different client
project].
This type of interaction was typical in that the consulting firm managers relied on the
timeline and the task report. Kevin, who was closest to the work, did not rely on the timeline as
much for information about the status of the project. But the other branch managers were less
familiar with the tasks, progress, and milestones, and referred to the timeline regularly to refresh
their memories. Kevin diligently updated the chart on a weekly basis, despite the fact that the
chart only documented the project falling further and further behind each week.
Synchronization. The use of timelines for synchronization was also apparent when the
client and consultant had to manage a set of changes to the accounting software. The OATS
project involved modifications to the same accounting system that the client used for customer
billing. As a public utility, the client had been granted a rate change as of a particular date; this
required modifications to the main accounting and billing systems. This was a major concern for
MWE, as Kevin reported:
Bernice [the manager of the MWE project manager] is really
worried about the time—if the department doesn’t make the
23
deadline, they lose 80% of that month’s billing.
When the OATS engagement was originally scheduled, this deadline was not an issue. But
given the delays in starting and the problem of the missing files, the rate change deadline became
critical. The project timeline provided a way for the client’s systems department and the
consulting team to synchronize their activities on the systems.
Thus, it is easy to identify the central importance of timelines as artifacts for scheduling,
allocating and synchronizing. They highlight the importance of time as a resource and provided
a quick, visual reference against which to measure progress. The interesting question is, how do
these timelines accomplish these critical functions for so many diverse groups and activities?
Pluritemporalism: Divergent Interpretations
Several different subgroups used the timelines during the OATS engagement: (1) ITCF
managers; (2) ITCF consultants; (3) MWE managers; (4) MWE systems people; and (5) the
MWE billing department, who paid ITCF’s invoices and would be the ultimate users of the
software. Additional groups could also be identified, such as the salespeople at ITCF, but they
played lesser roles in the consulting engagement itself, which is the focus of the analysis.
The groups involved in the project did not always share a common interpretation of the
timelines. For example, the ITCF managers saw the timelines as the basis for billing and
budgeting. To them, certain milestones were critical because they enabled issuance of an invoice
which would result in a payment for consulting services rendered. For example, after the first
week of searching for the missing files, a consulting manager was worried and frustrated:
They’ve blown this week on testing, and it’s a fixed price
contract.…We’ve lost 47 hours and someone has to pay for this.
Thus, timelines represented the economic dynamics of the engagement. These groups both
24
viewed time as money, and the passage of time on the chart indicated a set of implicit economic
transactions. Their MWE management counterparts saw these milestones as money, also, but
from a different perspective. Instead of income, the timeline represented bills to be paid.
The ITCF consultants, however, saw something entirely different. For them, the
milestones represented work to be done. When the work involved design, or new technology, it
was seen as a creative opportunity. For example, when hearing about the possibility of getting
assigned to the OATS project, one consultant was quite enthusiastic:
I like that assignment, because it will give me some good
experience, and the other people there will help me learn. I’ve
never had that experience before, so I think I can learn a lot on that
job.
When it involved routine testing or user training, it was seen as drudgery. For example,
during a lull in the OATS work, one of the consultants was assigned to do some training at
another site:
It’s so boring. Last time, we did “how to teach a skill” [he makes a
face]. Someone asked me right afterward, “what did we
learn?”—and I forgot!
Mundane technical work was anathema to these technical consultants. Searching for lost files
was also seen as grunt work. It was important, but there was no technical challenge.
In the case of the OATS engagement, the pressure of the fixed price contract added a
significant layer of meaning for ITCF managers and consulting staff. Because of a regulatory
requirement, the client was extremely concerned about completing the project on time. But
given all the delays, on-time completion of the project seemed increasingly unlikely as time
25
passed. In an effort to appease the client, and retain the possibility of follow-on work, managers
at the consulting firm wrote a letter to the client stating, in part, that they "would make every
effort to complete the testing on schedule, including working overtime if necessary and
appropriate." Unfortunately, with no money in the budget for overtime, the consulting staff was
asked to work extra hours without overtime pay. When Kevin confronted one of the consultants
for "not working hard enough," it led to what one of the other consultants described as a
"conflagration." Later, the consultant in question explained his anger: "I was working more than
50 hours a week already, which I think is too long. I don't want to do management, I just want to
be an analyst…" Kevin could not understand that attitude: "Why doesn't he want to see the
project go successfully?" Thus, certain phases of the timeline came to represent dozens of hours
a week of unpaid overtime for the consultants. By contrast, to Kevin and some of the other ITCF
managers, overtime worked served as evidence of the consultant’s commitment to the project’s
success.
Timelines as a Locus for Negotiation
Thus, timelines provided a focal point not only for consultant and client, but also for
members of the same firm to discuss the various interpretations of time throughout the project.
Indeed, in the examples that follow, the important insight is that any set of groups may use
timelines as a device for negotiating divergent views.
Form versus content. During the first project status meeting, the client discussed the
approval process for various tasks that were to be completed as part of the project. The client
explained that they preferred an approval process that would involve both a user and a technical
analyst. Kevin, the project manager, would request that a review be scheduled, and he, an MWE
user and an MWE technical analyst would meet to "walk through" the review and obtain all the
26
necessary signatures approving the completion of the task. The next week, Kevin was still trying
to "nail down" the details of this process and get preliminary information before what he called
"normal work mode." As a “technical person,” Kevin knew that he needed timely decisions in
order to move forward with the work. Yet his counterparts at MWE were accountants, not
technical people. They were unfamiliar with the technical content, and accustomed to multiple
layers of review; thus, they focused their attention on details and form rather than technical
content.
For example, non-technical (and, to the ITCF team, irrelevant) details such as the layout
of timeline itself became a focus of discussion at meetings with the client. Very early in the
project, Kevin had been eager to learn ITCF’s new project management software which would
aid in producing the project documents (including the timelines). Yet the first set of documents
produced were not readable: the timeline flowed over four pages without discernable breaks,
and the different symbols (/ , = , ^ , † ) were in small font such that the symbols were
indistinguishable. Kevin had to spend several hours revising the timeline; in spite of his
revisions, the MWE team was not satisfied with the timeline’s appearance. Directly after the
first meeting, the MWE project manager produced a memo that included the following points:
(a) the timeline needed to include more detail; and (b) the timeline should show detailed progress
against the plan. Kevin had simplified the chart to make it “readable,” so that providing more
detail meant that even more symbols had to be printing in a crowded area, making it even harder
to read and understand.
Kevin once again revised his timeline and, satisfied with the result, sent it to the client.
Two days later, another client memo arrived at his desk, asking for more detail on eight of the
fourteen high-level tasks in the timeline. He considered these trivial details of formatting and
27
would have preferred to focus on the technical issues, but the MWE project manager considered
these details important, and Kevin had no choice but to comply.
Naming and counting the tasks. During the engagement, there was on-going confusion
and disagreement over the tasks and their labels. When discussing the timeline, the parties
frequently became confused about what task was being referenced. For example, in the ITCF
timelines, each task had a number. In the more detailed timelines, the task numbers would
lengthen to indicate the hierarchical relationship of the tasks (i.e., task 3.1.4.26). Each of the
systems modules they modified also had a numerical designation taken from the OATS
documentation which differed from the timeline’s task numbering. For Kevin, this seemed like a
trivial detail, since he had the technical details of the engagement at his fingertips. Yet the
members of the client project team were confused by the different numbering systems, and were
unable to tell what was going on by a technical description of the task. After nearly every client
meeting, Kevin would receive a memo from MWE’s project manager seeking clarification of
these details. Kevin painstakingly developed a more detailed timeline and task list, but Kevin's
technical task descriptions were deemed too terse by the client team, and the numbering for the
tasks was still inconsistent in places. This problem was exacerbated when the client began
creating their own numbered list of tasks, which did not correspond with either the ITCF timeline
or systems module numbers.
After each meeting, there would be an exchange of memos and meetings, which were a
source of frustration for the consultants, who much preferred the technical tasks. But the
consultants were forced to attend to these “nit-picking” details, because the client held payment
on their invoices until every detail was completed to their satisfaction. In one particularly
annoying case, a sign-off sheet was sent back to be re-done, apparently because it had a barely-
28
perceptible coffee cup stain. In the face of a fixed price contract that had already gone over
budget, the consultants grew increasingly frustrated with the client’s attention to form over
technical content. After several months of this confusion, the client insisted Kevin merge the
lists. Kevin and I worked for the greater part of a day to produce that combined list.
The approval game. There was a seemingly endless memos and clarifications about
tasks, deadlines, and payments, most of which revolved around the timeline and its
interpretation. This is illustrated by the following examples, which are excerpted from three (out
of several hundred) memos collected during the engagement. For example, the client memo
concerning the approval of a scheduled deliverable early in the project stated:
We will approve the first package of specifications so that the
programmers coming on site on Monday can begin programming
immediately if ITCF can provide a schedule of delivery dates on the
missing components. We will withhold a portion of the payment
due at the end of the detail specification phase until all materials are
received.
In this way, the timelines were a locus for accountability because they described what
was to be done, and when, and by whom. The revised schedule of delivery dates was
incorporated into the next revised timeline. Thus, the timelines provided a means for the client
to hold the consultant accountable (and in the case of the missing files, vice versa). There were
numerous instances in the data where the client used the timeline to demand the accountability
from the consultants. To continue with the same example described above, the client was not
fully satisfied with what ITCF delivered, and chose to withhold payment as they noted in another
memo:
29
On November 2, the second of three detailed programming
specification packages was delivered for review. Although
exhibiting a greater consistency in terms of readability and
thoroughness, the specifications did not contain all the items
previously agreed to in the “Deliverable Format Package.” Since
ITCF has chosen to defer completion of these items by assigning
them to their programmers, an overall approval was not given. …
Continued problems of this type will likely result in a revision of
the payment schedule.
In this case, the client naturally wanted everything to conform to the timeline and,
wanting to hold the consultant accountable for the work, they used deviations from the timeline
as a justification for withholding payment. Yet when ITCF wanted to use the timeline to hold the
client responsible for warranting a working system (e.g., in the case of the missing files above),
ITCF were reluctant to “play hard ball,” opting instead to preserve the relationship.
As a result of the client’s refusal to approve the programming specifications described
above, programming work could not begin as scheduled. This cause considerable concern on the
part of the client:
One of ITCF’s programmers was only on-site November 2nd, and
his return is not expected until November 9th. As mentioned before,
any delay in programming could adversely affect the project
schedule.
This dispute arose because each side tended to focus on different parts or aspects of the
timeline. The client was focused on the “allocated hours” section of the documents. This part of
30
the documents listed every member of the ITCF team, and the number of hours each consultant
had worked various numbered tasks (an excerpt is reproduced in figure 2).
Insert figure 2 about here
The MWE project manager had noticed that the third programmer (“Senior Programmer
3”) had been scheduled to be on site that week (“week 20”), but that the programmer had not
been on site. For MWE, this “missing” programmer was like a broken promise; it signaled a
failure to dedicate the resources that they felt they had “paid” for. The consultants, on the other
hand, knew that the technical specifications for this coding task (“Task 4.14.3.8”) had yet to be
approved by MWE. Without MWE’s approval, the consultant could not begin work on that task,
and there was nothing else for this consultant to do at the MWE site. Since ITCF did not want its
staff to sit idle (especially on a fixed price contract), this programmer had been temporarily re-
assigned to a different client site. These kinds of disagreements and negotiations were a constant
source of friction between the client and the consultant. It seems clear that each side experienced
considerable frustration in their attempts to get the other side to adopt their viewpoint.
These disputes were exacerbated by the differing views of time in the two organizations
(ITCF and the client). ITCF, as a consulting firm that measured performance by the billable
hour, had a faster-paced culture. After all, time is money for a consultant and like any IT
consulting firm, ITCF put a premium on working efficiently and staying busy. The client
organization, however, exhibited a slower pace. Their activities were punctuated by rate
changes, which were relatively few and far between.
Naturally, these cultural differences were manifest in their negotiations over the timeline.
The client could not accept ITCF’s re-assignment of idle programmers (as in the example just
mentioned); but ITCF could not imagine leaving them idle. When it came time to for the client’s
31
systems department to make the changes in their billing program to reflect the new rates, they
scheduled six weeks for the work. During this period (which took longer than the planned six
weeks), the ITCF consultants could not use the system, so they were officially “on hiatus.” The
client expected the same team members to resume the OATS work after the hiatus was over. Of
course, ITCF had to reassign the members of the OATS team to other projects during this time,
which made it difficult to restart the project with the exact same people. The six-week interval
seemed “short” to the utility, since it was during this period that MWE had to code, test, and
bring online the changes to the billing system that would allow them to charge their customers
the newer rates. Yet while this six-week period seemed short to the utility, Kevin (as well as
other ITCFers) chafed at the delay: “We could lose Martin and Rose [two of the analysts who
had been reassigned to another client during this period].” Kevin was worried that the delay
would mean that these two analysts would wind up working on a different large project for a
Fortune 50 company.
Who should pay? The timelines served as a basis for negotiating over the cost and the
scope of work for the engagement, as well. As a result of the missing files problem, Kevin
decided to ask the client for additional resources to help solve the problem. This only seemed
fair, that since the client had assured them that all the files would be available, and they were not.
Kevin opined that he "didn't think the client was worried about the dollars." His manager
disagreed: "with a fixed cost contract, believe me, the client thinks they have spent their last
dollar on this project. They'll raise a stink." "I'm optimistic," replied Kevin.
At the next project status meeting with the client, Kevin had to explain that the project
was already over a week behind. He explained the "missing files" that were the cause of the
delay, and he asked the client to pay for a support person from the vendor company to help them
32
with this issue. The client, in the manager's words, then "raised a stink." In a subsequent memo
about this request, the client asked, "is this the last of the cost increases in this fixed price
contract?" Soon thereafter, when the project team attempted to get the client to approve and sign
off on a different set of tasks that had been completed, the client refused. These sign-offs were
crucial, because the payment from the client to the consulting firm was in installments, and the
installments were contingent on the approvals by the user and technical groups.
Kevin's optimism was quickly eroding. The timelines continued to show slippage, and
after a few months the consulting firm was forced to drop their request for additional resources.
Kevin quietly worked additional hours to sort out the "missing files" problem. Ironically, it was
later discovered that these files had not been installed by the client. An underlying issue here
concerned who should be accountable for the work. This information was specified in the
detailed sheets that supported the main timeline. Because the timeline assigned tasks to
particular individuals, it provided a powerful mechanism for allocating responsibility, as well.
TIMELINES AS TEMPORAL BOUNDARY OBJECTS
Some readers may be concerned that it is difficult to generalize from a single consulting
engagement between two organizations. While this case clearly has a variety of idiosyncratic
features, the interpretations of timelines reported here are typical of consultants and their clients.
But the specific interpretations are not the main contribution of this research. Rather, the goal
has been to demonstrate how different organizational or occupational groups can come together
around a particular kind of taken-for-granted cultural artifact: the timeline. On this level, the
phenomena reported here are suggestive of the following:
1) Different organizational groups are likely to have different assumptions and concepts of
time.
33
2) In complex projects requiring the coordination of different groups, time will always be a
matter for conflict and negotiation.
3) To make time visible and negotiable, temporal boundary objects are useful.
4) Temporal boundary objects are essentially narrative representations that allow diverse
groups to “fill-in” and negotiate as they see fit.
Boundary objects are the practical artifacts that allow diverse groups to work together.
They provide a locus for communication, conflict and coordination. In this study, we have
examined a special class of temporal boundary objects that support coordination of time. Unlike
clocks or calendars, which measure time, timelines provide a graphical representation of time.
As we have seen, these representations give time an objective quality that would otherwise be
impossible to achieve. As Bucciarelli (1988) notes, "milestone charts" function as visions of
permanence, certainty, and order. In a very real sense, the process of creating and agreeing upon
the timeline created and imposed order onto an otherwise incoherent (nameless) set of activities.
By objectifying time in this way, they make temporal coordination possible.
As we have seen in the OATS engagement, different cultural groups “filled in” the story
quite differently (e.g., ITCF consultants versus MWE managers). These differences may be
attributed to differing assumptions about time, as well as other differences (e.g., emphasis on
form versus content). The narrative quality of the timeline is critical in this regard, because this
“filling in” is the process through which the work proceeds. As time passes, the story unfolds,
and the timeline changes accordingly. Unlike other boundary objects, which may remain
relatively stable over time, a timeline changes with each passing day. As the OATS engagement
drew to a close, Kevin stopped producing timelines; there was nothing left to “fill in.”
Clearly, timelines require interpretation. Their graphical format represents a picture of the
34
engagement or performance before it exists or is performed, giving project participants a means
of discussing tasks which have not yet been executed. In actuality, the technical tasks rarely
conformed to the neat units that were laid out on the page. During the engagement, these charts
were revised constantly. From the minute they are created, they are “wrong.” A project
manager from a different firm showed me how he took this into account: tasks with missed
deadlines were symbolized by a line of banana peels. In the OATS engagement, the consultants
were "behind" before they started, and they never really caught up. The "fixed price" aspect of
this made this even more problematic. Eventually, the work was completed, but many new
timelines had to be created and recreated to accommodate the missed deadlines.
Everyone who has worked on a systems project knows that the milestones so neatly
printed on first set of timelines are rarely met. Timelines portray events prospectively; in some
cases, the events never happen. Thus, timelines give participants an illusion of “management” or
“control” of the project. One cannot fully anticipate all of the events that may occur during a
project, and so it is only natural that changes emerge. For example, timelines would never
anticipate a heart attack of a key team member. But unanticipated events are possible. The
remarkable aspect of the phenomenon is that participants assign permanence to these
constructions. In spite of being distant representations of an uncertain future, these simple charts
are treated as concrete realities.
By having an orderly representation of the project tasks, both the consultant and client
could discuss the project as if it were well-defined. Like a security blanket, these timelines
allowed both parties to “see” the progress of the engagement, even when events made it seem as
if little progress was being made. Timelines did allow the parties to confront realities about
foreseeable events that potentially interfered with the project schedule—events such as
35
vacations, or regulatory deadlines. Especially during the earlier parts of the engagement, the
timeline gave the client as well as the consultant some sense of progress. The modules of
software code being produced were not visible to the client, so the timeline allowed both parties
to follow the progress of the tasks in an apparently concrete way. Indeed, the timeline was a key
part of every client report.
The content of the weekly progress report highlights some additional facts about
timelines. First, the documents themselves are not self-explanatory. The annotations that
accompany the charts provide important details that are needed to interpret the story in context.
These details, such as the task list and the numbering system, can be an enormous source of
confusion and negotiation. At the same time, everyone knows that the picture doesn't tell the
whole story. As the OATS project unfolded, the picture was continuously updated in an effort to
reflect reality. The client started to view the timelines with increasing suspicion and demanded
more clarifications. After all, six months into the project, the work was supposed to be done.
Even though it was a fixed price contract, continued development was not costless for the client,
either. Nevertheless, the timeline was the primary vehicle through which the participants
negotiated their understanding of the project.
On a more subtle level, the timelines can be viewed as "standing for" the systems
themselves, especially in the early phases of the engagement. In a sense, the timelines
themselves were the most tangible work product during the time when the actual software was
under construction. This is because when the task consists of "searching for files", there is no
tangible product (especially if the files are never found). Even when the consultants were
actively writing code, their work product was difficult to quantify. Hence, time itself, as
represented on the project timeline, came to stand for the actual work.
36
CONCLUSION
In theory, time can be measured in uniform, discrete units. This critical assumption
enables us to use clocks and calendars to quantify the passage of time. In organizations,
however, we need to do more with time than simply measure it. We need to allocate, schedule,
and synchronize activities. Thus, in practice, clocks and calendars are not sufficient.
We use timelines to render time visible and concrete. Timelines transforms the abstract
and existential nature of time into a concrete, observable story. Like clocks, timelines embody
objectivist, monotemporal assumptions about time, yet they are used in settings where diverse
organizational and occupational subgroups have different assumptions about time. Thus,
timelines function as temporal boundary objects, which allow participants from different groups
to negotiate and coordinate their work.
Timelines create a visual representation of a project that can be used for a wide range of
functions. Each occupational group involved in a project can preserve its own local
interpretation (over time, on time, down time, etc.) and still coordinate and negotiate their mutual
activities as needed. The visual nature of the chart itself is critical to this. On one hand, it is
flexible and robust enough to allow participants to "fill in" and make meaning where they see fit.
On the other hand, it creates the impression of concreteness that belies the inherent uncertainty
underneath. This allows the chart to be both useful and credible. These mundane
representational tools serve to transform an uncertain outcome into a sought-after ending for all
participants, despite their divergent interests and interpretations.
37
REFERENCES
Abbott, A. 1990. A primer on sequence methods. Organization Science, 1: 375-392.
Adam, B. 1990. Time and social theory. Philadelphia: Temple University Press.
Adam, B. 1995. Timewatch: The social analysis of time. New York: Polity Press.
Agar, M. 1996. The professional stranger. New York: Academic Press.
Barley, S. R. 1988. On technology, time, and social order. In F. Dubinskas (Ed.), Making time:
Ethnographies of high-technology organizations: 123-169. Philadelphia: Temple University
Press.
Barry, A. M. 1997. Visual intelligence. Albany, NY: State University of New York Press.
Bergmann, W. 1992. The problem of time in sociology. Time and Society, 1: 81-135.
Bloomfield, B. P., & Danieli, A. 1995. The role of management consultants in the development
of information technology. Journal of Management Studies, 32: 23-46.
Boreham, P. 1983. Indetermination: Professional knowledge, organization, and control.
Sociological Review, 31: 693-718.
Borst, A. 1993. The ordering of time: From the ancient computus to the modern computer (A.
Winnard, Trans.). Chicago: University of Chicago Press.
Borum, F., & Pederson, J. S. 1990. Understanding IT people, their subcultures, and the
implications for management of technology. In F. Borum & P. H. Kristensen (Eds.),
Technological innovation & organizational change: 219-241. Copenhagen: New Social Science
Monographs.
Bowen, D. E., & Schneider, B. 1988. Services marketing and management: Implications for
organizational behavior. Research in Organizational Behavior, 10: 43-80.
Brooks, F. P. 1975. The mythical man month. Reading, MA: Addison-Wesley.
38
Bruner, J. S. 1990. Acts of meaning. Cambridge, MA: Harvard University Press.
Bucciarelli, L. L. 1988. Engineering design process. In F. A. Dubinskas (Ed.), Making time:
Ethnographies of high-technology organizations: 92-122. Philadelphia: Temple U. Press.
Bucciarelli, L. L. 1994. Designing engineers. Cambridge, MA: MIT Press.
Clark, W. 1922. The Gantt chart: A working tool of management. New York: The Ronald Press.
Dubinskas, F. A. 1988a. Cultural constructions. In F. A. Dubinskas (Ed.), Making time:
Ethnographies of high-technology organizations: 3-38. Philadelphia: Temple University Press.
Dubinskas, F. A. 1988b. Janus organizations: Scientists and managers in genetic engineering
firms. In F. A. Dubinskas (Ed.), Making time: Ethnographies of high-technology organizations:
170-232. Philadelphia: Temple University Press.
Elias, N. 1992. Time: An essay. Cambridge, MA: Blackwell.
Gagliardi, P. 1990. Artifacts as pathways and remains of organizational life. In P. Gagliardi
(Ed.), Symbols and artifacts: Views of the corporate landscape: 3-40. New York: Aldine de
Gruyter.
Giddens, A. 1984. The constitution of society. Berkeley, CA: University of California Press.
Goodwin, C. 1994. Professional vision. American Anthropologist, 96: 606-633.
Gurvitch, G. 1964. The spectrum of social time. Dordrecht: D. Reidel.
Hall, E. T. 1989. The dance of life: The other dimension of time. New York: Anchor.
Hassard, J. 1990. Introduction. In J. Hassard (Ed.), Sociology of time: 1-18. NY: St. Martin's.
Hassard, J. 1991. Aspects of time in organizations. Human Relations, 44: 105-125.
Hassard, J. 1996. Images of time in work and organization. In S. R. Clegg, C. Hardy & W. Nord
(Eds.), Handbook of organization studies: 581-598. Thousand Oaks, CA: Sage.
Henderson, K. 1991. Flexible sketches and inflexible data bases. Science, Technology, and
39
Human Values, 16: 448-473.
Henderson, K. 1999. On line, on paper: Visual representations, visual culture, and computer
graphics in design engineering. Cambridge: MIT Press.
Lee, H., & Liebenau, J. 1999. Time in organizational studies. Organization Studies, 20: 1035-
1058.
Levin, R. I., & Kirkpatrick, C. A. 1966. Planning and control with PERT/CPM. NY: McGraw-
Hill.
Marks, N. E., Taylor, H. L., Schoen, G. W., & Susbauer, J. C. 1966. CPM/PERT: A
diagrammatic scheduling procedure. Austin, TX: Bureau of Business Research.
Mills, P. K. 1986. Managing service industries. Cambridge: Ballinger.
Mulvaney, J. E. 1969. Analysis bar charting: A simplified critical path analysis technique.
Washington, D.C.: Management Planning and Control Systems.
Nandhakumar, J., & Jones, M. 2001. Accounting for time: Managing time in project-based team-
working. Accounting, Organisations and Society, 26: 193-214.
Nowotny, H. 1992. Time and social theory. Time and Society, 1: 421-454.
Ochs, E. 1997. Narrative. In T. A. van Dijk (Ed.), Discourse as structure and process: 185-207.
Newbury Park, CA: Sage.
Rathe, A. W. 1961. Gantt on management: Guidelines for today's executive. NY: AMA.
Reich, R. 1991. The work of nations. New York: Knopf.
Roy, D. 1959. "Banana time:" Job satisfaction & informal interaction. Human Organization, 18: 158-
168.
Sanjek, R. 1990. Fieldnotes: The makings of anthropology. Ithaca, NY: Cornell University Press.
Sapolsky, H. M. 1972. The Polaris system development. Cambridge: Harvard University Press.
40
Sharron, A. 1982. Dimensions of time. Studies in Symbolic Interaction, 4: 63-89.
Spradley, J. S. 1980. Participant observation. New York: Holt.
Star, S. L. 1991. The sociology of the invisible. In D. R. Maines (Ed.), Social organization and
social process: Essays in honor of Anselm Strauss: 265-283. New York: Aldine de Gruyter.
Star, S. L. 1999. The ethnography of infrastructure. American Behavioral Scientist, 43: 377-391.
Star, S. L., & Griesemer, L. 1989. Institutional ecology, "translations," and boundary objects.
Social Studies of Science, 19: 387-420.
Strauss, A. L. 1987. Qualitative analysis for social scientists. NY: Cambridge University Press.
Strauss, A. L., & Corbin, J. 1990. Basics of qualitative research. Newbury Park, CA: Sage.
Strauss, A., Schatzman, L., Ehrlich, D., Bucher, R., & Sabshin, M. 1964. The hospital and its
negotiated order. In E. Freidson (Ed.), The hospital in modern society: 147-169. NY: Free Press.
Thompson, E. P. 1967. Time, work-discipline, & industrial capitalism. Past & Present, 38: 56-97.
Trabold, F. W. 1922. How a manager uses Gantt charts. In W. Clark (Ed.), The Gantt chart: A
working tool of management:143-150. New York: The Ronald Press Company.
Traweek, S. 1988. Discovering machines. In F. A. Dubinskas (Ed.), Making time: Ethnographies
of high-technology organizations: 39-91. Philadelphia: Temple University Press.
Trice, H. 1993. Occupational subcultures in the workplace. Ithaca, NY: Cornell University Press.
Van Maanen, J. 1988. Tales of the field: On writing ethnography. Chicago: U. of Chicago Press.
Van Maanen, J., & Barley, S. 1984. Occupational communities: Culture and control in
organizations. Research in Organizational Behavior, 6: 287-365.
Weick, K. 1995. Sensemaking in organizations. Thousand Oaks, CA: Sage.
Yakura, E. 2001. Billables: The valorization of time in consulting. American Behavioral
Scientist, 44: 1076-1095.
41
Yates, J. 1989. Control through communication: The rise of system in American management.
Baltimore, MD: John Hopkins University Press.
Zaheer, S., Albert, S., & Zaheer, A. 1999. Time scales and organizational theory. Academy of
Management Review, 24: 725-741.
Zerubavel, E. 1979. Private time and public time. Social Forces, 51: 38-58.
Zerubavel, E. 1981. Hidden rhythms: Schedules & calendars in social life. Chicago: U. of
Chicago.
42
FIGURE 1
A Timeline for the OATS Project
FIGURE 2
Excerpt from Allocated Hours Chart of Sr. Programmer 3
Senior Programmer 3
week 16 week 17 week 18 week 19 week 20 TOTALTask 4.14.3.5 32 17 49Task 4.14.3.6 21 12 33Task 4.14.3.7 31 8 39Task 4.14.3.8
43
AUTHOR BIOGRAPHICAL SKETCH
Elaine K. Yakura earned a Ph.D. at the Massachusetts Institute of Technology, and a J.D. at
University of California Berkeley. She is an assistant professor at the School of Labor &
Industrial Relations, Michigan State University. Her research interests include the study of power
and difference in organizations through long-term participant observation.