The Iterative Design of a Project Charter
for Interdisciplinary Research
Humanities Computing Program
Department of English & Film Studies
3-5 Humanities Centre
University of Alberta
Edmonton AB T6G 2E5 CANADA
Electronic Publishing Program
Centre for Communication Studies
4825 Mount Royal Gate SW
Calgary AB T3E 6K6 CANADA
This paper describes our experience with the iterative
development and use of a project charter for helping to manage
expectations of the various members of interdisciplinary research
teams. Some of our team members may be working with other
researchers for the first time, and many of them have not worked
previously with researchers from other disciplines. The charter is
based on the need to explicitly discuss principles and policies of
research practice with people from different disciplines at the
start of the project, and to have a common agreement to refer to
if necessary during the project. Our current template contains the
•We are interested in disseminating the results of this
project as widely as possible, with credit to us for doing it.
•We intend this work to move forward at a steady pace,
given due awareness of the vagaries of life.
•We would prefer for this work to be funded.
•We understand that the work we do on this project may
have future phases. Modifications and additions may be
made to further the project by other members.
•We wish to communicate in such a way as to preserve
•We would like to foster goodwill among all the
Although these seem on the surface like motherhood statements
that would go without saying, in practical terms these principles,
and the longer list of policies that emerge from them, are actually
the basis of fundamental misunderstandings between disciplines.
Categories and Subject Descriptors
H.1.m [Information Systems]: Miscellaneous
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Conference’04, Month 1–2, 2004, City, State, Country.
Copyright 2004 ACM 1-58113-000-0/00/0004…$5.00.
Computer-Human Interaction, Interface Design,
Interdisciplinarity, Team management
It has become increasingly common to hear people speak highly
of collaborative research. As Hara et al. (2003) point out,
collaboration can be a critical component for success, especially
in cases where people are tackling complex, real-world
problems. The traditional academic emphasis on specialization
combined with the related wealth of research publication means
that individual researchers are not able to do everything needed
to make significant contributions. This reality is slowly working
its way into the research infrastructure, in the form of new and
better funding programs. In Canada, for example, the Social
Sciences and Humanities Research Council has for some time
awarded one or two Major Collaborative Research Initiative
grants each year, and has recently announced a new funding
program intended to help Canadians to lead and participate in
international collaborative research projects (SSHRC, 2007).
In this paper, we outline the lessons we have learned over the
past five years in carrying out approximately 30 interdisciplinary
design research projects. Many of these projects are in the area of
humanities visualization (Ruecker 2006); most are still ongoing.
Humanities visualization typically involves experimental
interface designs that show complex displays and tools for
dealing with digital collections of texts or images. Our research
is often intensely interdisciplinary, with no two members of a
project sharing a common disciplinary background. We have
worked so far with colleagues in approximately a dozen
disciplines, including computer science, psychology, humanities
computing, sociology, visual communication design, city
planning, political science, pharmacy, communications studies,
English literature, library and information studies, and chemical
and materials engineering. Our research projects have ranged
from teams of three or four local members (www.humviz.org) to
as many as fifty researchers at seven universities
(www.monkproject.org). Some of our people come from well-
established research disciplines with clearly-defined expectations
(e.g. Psychology), while others are from emerging disciplines
where traditions for research methods and dissemination of
results are not yet firmly established (e.g. visual communication
design). Both kinds of researchers constitute a challenge for
design research teams, and experience has taught us that it is a
useful practice to make all expectations as explicit as possible.
In 2005, we began iteratively designing a project charter that
spells out the principles under which we operate, as well as the
specific policies that are related to each principle. We typically
introduce the charter individually to new team members as they
are recruited, or else within the first meeting or two of the entire
team, then refer to it subsequently as team issues come to light.
We propose to discuss this evolving charter template in the
context of our research experiences, in the hope of making the
results of these experiences available in a useful form for the
larger design research community.
2. RELATED WORK
There are varying research traditions in the academy. Speaking
in broad generalizations that do not always apply, some
disciplines, particularly in the humanities, have tended to expect
work to be done by a lone scholar, working within a tradition,
presenting results to a scholarly community, and training
graduate students who will also work alone. Other disciplines,
particularly in the sciences and engineering, have adopted
instead an apprenticeship model, where a senior scholar manages
a lab where junior scholars work. A third model is one in which
groups of established scholars work together. They might share a
specialized background, or more typically a disciplinary one.
This discipline-based model capitalizes on the benefits of
specialization – specialist scholars refine theories, methods, and
technologies particular to their disciplines (Seipel, 2005).
Interdisciplinary research models build on the strengths of the
third, discipline-based model. We define interdisciplinary
research as combining two or more academic disciplines that are
usually considered distinct in order to reach a common goal. The
concept has been further articulated as unidisciplinarity (Hobson,
nd), multidisciplinarity (Wilson & Pirrie, 2000), or
pluridisciplinarity (Sillitoe, 2004), depending on the ways in
which the teams functionally interact. We have teams that fall
into each of these categories depending on the nature of the
project, the experience of the people on the project, and their
willingness, need and ability to work together. For example, in
our project on interfaces for visualization of simplex decision
support systems, the mathematical modeling is handled in a
unidisciplinary manner by the project engineers, while the
interface design is similarly carried out by a relatively isolated
team of designers. In contrast, our project on developing a rich
prospect interface for pill identification involved designers,
programmers, and information specialists working together at the
same table over an extended period, providing each other with
relevant literature and insights that crossed disciplinary
Genuinely interdisciplinary work is valuable for several reasons.
First, it is possible to tackle problems in an interdisciplinary
project that could not be dealt with in any adequate way by a
single researcher working in the confines of one discipline. As
Sillitoe (2004) explains when discussing his interdisciplinary
work on poverty, complex research problems often require the
cooperation between specialists with diverse backgrounds, in his
case, in both the natural and social sciences. Second, the projects
themselves can be remarkably fruitful to the researchers
However, although the benefits of interdisciplinary work are
significant, it does not come without problems and challenges.
To begin with, some disciplines are more open towards inter-
disciplinary work than others. Therefore, when forming a team,
we have had to become conscious that not everyone may have
had previous experience working in such a manner. As it often
occurs on our projects, some team members come to the table
unaware of the methods and processes inherent in each other’s
research practice. A form of artful integration (Schuler &
Clement, 2004) is needed – a careful weaving of complementary
researchers, methodologies, and practices. In our experience, a
project that is made up of a team of researchers who are
unknown to one another is particularly challenging. The start of a
project does not allow enough time for everyone to become
adequately acquainted. By the end of the project, however, our
team members seem to gain a substantial awareness of each
other’s value, particularly if they worked in a pluridisciplinary
manner. This knowledge is of great advantage on subsequent
Another challenge occurs when a project begins to go astray.
This can occur for a number of reasons, and, as the literature
reports, it can take weeks or even months before all of the team
members are aware of what has happened (Keil et al., 2004).
Interdisciplinary research requires a combination of new sets of
skills and accommodation of other team members in a number of
areas where accommodation may not otherwise have been
necessary. Hara et al., (2003) outline the following factors
•Other forms of compatibility (Hara et al., 2003)
In the context of advice for people undertaking interdisciplinary
work for the first time, Svensson (2003) has a list of strategies:
•open yourself up to neighboring fields
•map the relevant conceptual territory
•be prepared to find unexpected connections
•communicate with people unlike yourself
•think across boundaries
•make sure to introduce interdisciplinary strategies early
in the process (Svensson 2003)
In addition to interpersonal management strategies, several
technological solutions for project management have been
developed and subsequently adapted to interdisciplinary research
management. Microsoft Project Management and the online
Basecamp are two popular examples. Research continues in this
area with projects such as Zhang et al. (2007), who designed and
implemented a research prototype called ACPM (Activity Centric
Project Management). The goal of the system is to make
collaborative activities flexible and easier to manage. Their
findings indicate that an activity-centred approach could be used
to integrate tasks and activities, provide timely activity reports,
generate status reports, and allow third-party access to the
information, thus helping to manage collaboration.
Finally, no interdisciplinary research project can be expected to
succeed unless it has contributions from good team members:
"The most important features of project-relevant skills and
knowledge appear to be diversity and complementarity in the
skills, perspectives, and knowledge of team members" (Amabile
et al, 2001). As one of our colleagues recently put it during a
presentation with seven authors (Wynne et al. 2007), on a good
interdisciplinary project, each team member is uniquely valuable
– no one is expected to compromise his or her own expertise.
Across its various incarnations, the interface design she was
discussing has involved expertise from five disciplines:
psychology, humanities computing, computer science, visual
communication design, and library and information studies (see
Figure 1. This image browser was originally designed by a team working on pill identification (Given, Ruecker, Ruskin, Plouffe,
Simpson, and Sadler). It was subsequently repurposed as a system for helping conference delegates manage social capital
(Ruecker, Lewcio, Plouffe, and Wynne), and in this third version, it has been adapted to help answer some questions raised by
the statistical analysis of crayon pictures drawn by elementary school children (Wynne, Ruecker, Nelson, Albakry, Strong,
Lewcio, and Plouffe
Figure 2. Sometimes a larger interdisciplinary research project will contain components that are complex enough to require the
collaboration of several people from a single domain. In NORA (short for No One Remembers Acronyms) we were attempting to
repurpose for literary scholars the D2K datamining system at the National Center for Supercomputing Applications. At least
four designers worked on the various interfaces, including this one that appears in the final online demo (www.noraproject.org).
3. TEAM MANAGEMENT
“If you let go of your own agenda when coming to the
table made up of an interdisciplinary team, more creative
"stuff" tends to emerge. you take true advantage of the
interdisciplinary team by not trying to force your own set
of values or processes onto them. and, as you've
experienced, forcing it doesn't work anyway – they rebel.
with interdisciplinary design research you can ask even
larger questions, and when you allow those teams to do
their own thing, even more creative and unexpected
outcomes occur” (Zimmerman, 2003).
Our typical research team involves 3-5 researchers, each of whom
sits in a different disciplinary chair. It will occasionally happen that
a project requires, for instance, four designers (see Figure 2), but
most projects will have a designer, a computer programmer or two,
a domain expert, and a project manager.
In the standard military model of organization, there would be a
hierarchy, where the manager would determine what was going to
be accomplished, then divide the work among the others. This form
of delegation is not viable for interdisciplinary research, where
there are usually no clear lines of reporting that can be used to
enforce authority. In different projects the various roles might be
filled by colleagues at approximately equal points in their career
trajectory, or there may be senior colleagues with junior colleagues,
full professors with graduate or undergraduate students, industry
partners, faculty members from different departments, and so on.
Under these conditions, delegation from a single authority is
problematic, because there is no single authority. It is therefore
useful to treat the team members as equals, and to attempt to foster
a genuinely collaborative management environment rather than
adopt a fiction of central control and delegation.
The decision to work collaboratively has significant implications
for the direction the project will take. In fact, we have noticed that
everything about a project would be different if there were a
different person in any of the chairs. Since each chair represents a
specialization, the decisions made by each participant will directly
influence the way the project proceeds. In general, we typically
have a goal for the project before the team is assembled. However,
all of the strategic decisions about content, platform, visual
language, protocols for user study, and so on are determined by the
This policy on strategic decision-making is an example of the
iterative nature of our ongoing Project Charter design process. We
only slowly came to the realization that it was a good idea to have
our research colleagues determine the project strategy, having
noticed that our setting both a goal and a corresponding strategy
was inevitably leading after the first few meetings to a point of
rebellion, where one or more of the participants would propose an
alternative strategy to the one being discussed. It became clear that
this key moment in the process was one where additional
commitment and motivation was being generated, and we began to
start projects without the initial strategy, recognizing that it would
be discarded in any case. We wondered at first if discarding the
initial strategy was an essential part of creating motivation, but
when we removed that step, we found that the moment where
participant enthusiasm was generated simply arrived two or three
Another example of the iterative development of the charter is the
policy on dissemination. We originally were concerned only with
presentation at conferences and publication in academic journals,
and the policies dealt with the issue of co-authorship. Over time,
however, it became plain that we were also tending to adopt online
methods of disseminating our work, including web sites, blogs, and
wikis, and we added a policy so that this form of dissemination
would become part of our early discussions.
Based on these experiences we have come to our own pragmatic
understanding of Sillitoe’s comment (2004) that interdisciplinary
team management is a balancing act between respecting the needs
and perspectives of individual researchers on the team and the
canons of their disciplines, and supporting the goals of the project.
4. THE PROJECT CHARTER
The current form of the project charter contains six major sections,
which correspond to the principles under which we carry out our
projects. For each principle, there are a number of policies that
address specific questions of interpretation. The six principles deal
respectively with dissemination, deadlines, funding, future phases,
professional dignity, and goodwill. We do not consider this to be an
exhaustive list of principles – it is simply the list we have
iteratively developed so far, based on our experiments in project
management. This charter is currently on its 14th iteration.
Principle: We are interested in disseminating the results of this
project as widely as possible, with credit to us for doing it.
The principle of dissemination may at first glance appear
unnecessary, since academics place a high premium on publication.
However, for colleagues in the fine arts, publication is not
necessarily as important as exhibitions or gallery shows. For
colleagues in English Departments, the highest form of publication
is the book. For colleagues in Computer Science Departments,
conference proceedings are more important than books, because the
book is generally considered an archival record of past research,
whereas conferences are at the cutting edge. In Humanities
Computing, the conferences are often based on abstracts only,
rather than full papers; the result is that presentation at even the
most venerable Humanities Computing conference is not usually
beneficial for Computer Scientists.
In addition to the disciplinary variations in evaluating publication
venues, there are also cases where colleagues on a research project
are from industry. In these situations, especially if there has been a
monetary contribution from the industry partner, it is very
important to agree at an early stage about what can be published
and when. For colleagues in areas where intellectual property can
be valuable, it may also be important to have patent applications in
place before results are published to the academic community.
Fortunately, interface designs are generally not patentable, which
reduces the anxiety somewhat in our field.
Policy: Project members may use any of it as examples in
presentations, papers, interviews, and other media opportunities.
They may post any of it to their web sites. Wherever possible, they
should mention the names of the other project members who were
directly involved, as well as the name of the project.
There are many occasions where it is possible to mention a project.
This policy encourages our team members to mention our work,
even in cases where it is not reasonable to provide a co-authorship
credit to every team member. Since the principle is to disseminate
our results, these occasional descriptions can have a very beneficial
effect. In this paper, for example, we have on principle, and
perhaps somewhat gratuitously, included the names of the
researchers in the figure captions.
Policy: The project team will maintain a collaborative project web
site, which will contain links to all the presentations and
publications of the group.
The web is a convenient place for team members to access and to
point at whenever someone is interested in our projects. However,
setting up and maintaining a web presence is a service load on the
project, and needs to be explicitly endorsed or it can easily slip
through the cracks. Examples of project sites related to our work
include http://humviz.org, www.noraproject.org, www.hci-
book.org/cluster/, and www.monkproject.org.
Policy: For presentations or papers where this work is the main
topic, all team members who worked directly on this subproject
should be co-authors. Any member can elect at any time not to be
listed, but may not veto publication.
The policy on co-authorship can result in papers with quite a few
authors. We now typically have 3-5 authors on every paper, and our
longest list so far includes 7 authors. Multi-authored papers are
commonplace in the sciences but still relatively rare in the
humanities. In any case, they are a good opportunity for junior
colleagues to present and publish. However, on one of our larger
projects, we have a team of over 25 faculty members, not including
postdocs and graduate students. We have deliberately planned the
project so that the work will be tightly integrated, which will make
the choice of co-authors very difficult. For that project, we have
modified this policy to provide for individually naming the first
three authors, then listing the name of the research group as the
fourth author. The members of the group can then be listed in a
Policy: For presentations or papers that spin off from this work,
only those members directly involved need to be listed as co-
authors. The others should be mentioned if possible in the
acknowledgments, credits, or article citations.
The goal here is to provide a reasonable way to balance the benefit
of co-authorship with the possible growth in the numbers of co-
authors that begins to reduce that benefit. By suggesting when
acknowledgment or citation is appropriate, the policy provides a
useful approach to promoting our work without overwhelming the
Principle: We intend this work to move forward at a steady pace,
given due awareness of the vagaries of life.
Deadlines are important to the success of a project, but a positive
ongoing relationship between the researchers is also important. It is
therefore useful to acknowledge that deadlines are important, but
that a steady forward pace is really what is required.
Policy: project members will make every effort to attend meetings
as arranged and to keep in regular contact by email or other
electronic means. Frequent absence may result in being warned,
then cautioned, then asked to leave the team.
Communication is distinct from the timelines of a project, and
people have to be among those present in order to communicate.
We generally assume that on interdisciplinary research projects, it
is a fundamental fact that people will vote with their feet, and
decisions will be made and enacted by the people who are present.
However, we also recognize that not everyone can be present all
the time. At key points in some projects, when deadlines are tight,
we have supplemented this policy with another provisional one,
that specifies turnaround time on decisions. Under these unusual
conditions, people who do no respond within 24 hours, for
instance, are assumed to consent.
Policy: Project members will jointly establish and attempt to meet
self-imposed deadlines, in part through providing the project
administrator with lists of commitments, so that reminders will be
sent out as a matter of routine.
It is not always possible for projects to have an official
administrator, and it is a bit of a luxury when they do. However,
the strategy of explicitly notifying the other team members of
commitments and deadlines can help keep a project moving
forward. However, the spirit of this policy needs to be read in the
context of the larger principle that allows for the vagaries of life.
This policy is also an example of the iterative development of the
charter, which sometimes requires revision to existing policies to
accommodate new circumstances. The original form dealt only with
self-imposed deadlines, but when we had the opportunity to hire a
project administrator, we added the second clause. Although this
may seem like a comparatively minor change in wording, in
practice it is a significantly different approach to handling
communication about deadlines.
Policy: In the event the task is overdue by a considerable amount of
time (for instance, whichever is lesser–two months, or double the
original timeframe), other members may at their discretion notify
the offender that the task will be re-assigned, without prejudice to
the constitution of the team or the public credit of any member.
Even given the vagaries of life, it is sometimes the case that a team
member simply does not meet deadlines. It is important to be able
to re-assign the tasks undertaken by such a person, although it is
also worth trying to figure out if there are useful tasks that do not
require the person to meet a deadline. There are often tasks that
just need to be completed at some point during the process.
Examples include writing sections of text for the web site or blog,
coming up with interesting titles for presentations and papers,
carrying out literature reviews and writing up the results, and
starting on the next grant proposal.
This policy is another instance where the charter has varied from
project to project. On one of the major international projects, the
need to co-ordinate efforts between teams meant that a deadline
slipped by two months would be too much, and we not only
shortened the duration in the policy, but also wrote the project plan
to include monthly updates from the team leaders.
Policy: Project phases will be arranged so as to minimize the need
for sequential completion of one phase before another can begin:
wherever possible, phases will run in parallel, with communication
occurring between people as they work on each phase, rather than
waiting to communicate until the end.
Of all the policies dealing with timelines, this one is perhaps the
most important. Projects occur over time, which means that they
will go through phases. But on an interdisciplinary project, it is a
fundamental error to require one group of researchers to wait on
output from another group before they can begin. It is one thing to
fall behind because your own work is going slower than you’d
planned. It is quite another experience to be waiting for months or
even years for someone else to give you what you need to start your
Principle: We would prefer for this work to be funded.
Since funding is often quite competitive and is in many cases
coupled to the primary research objectives of the principal
investigator, it is not always possible to secure research funds for
interdisciplinary projects. We have several projects that are being
carried out by groups of volunteer researchers who happen to share
a common interest. However, in each of these cases we would be
able to make faster progress and also provide rewards if some
funding could be secured. This principle lets the researchers know
that it isn’t necessarily neglect that has resulted in a project
moving ahead without funding, and that we will do our best to
secure funding when we can. At that point, there are additional
management considerations, since most agencies will not
retroactively fund researchers who have been working as
volunteers. One possibility is therefore to use conference travel as
a reward that is not retroactive but nonetheless relies on the work
having moved ahead to the point where it is ready to present.
Policy: Project members will watch for and notify each other of
funding opportunities and participate wherever possible in the
writing of appropriate grant proposals.
Given the realities of competitive funding and small pots of money
in various locations, academic research can quickly become a
never-ending process of writing research grants, some of which can
be quite time-consuming. Perhaps not surprisingly, the size of the
award does not usually correlate in any meaningful way with the
amount of work involved in applying for it. Getting help from other
team members in grant writing can strengthen relationships, serve
as a learning experience for junior colleagues, and also be used as
an early phase in collaborative project planning.
4.4 Future phases
Principle: We understand that the work we do on this project may
have future phases. Modifications and additions may be made to
further the project by other members.
People realize that research has phases that will occur over time.
They also know that they may lose interest in the project, or find
other projects that are more interesting, or move on to other kinds
of work instead of research. However, it is important to have the
principle in place so that team members have a chance to
acknowledge to themselves that the project may not end with the
end of their participation.
Policy: In addition to PDFs or other formats for presentation,
project members will keep safe and distribute regularly all native
files generated for the project: Photoshop, Illustrator, Flash,
InDesign, and any other data files or source files. These files will
be unflattened and editable. Where copyright restrictions do not
apply, fonts should also be included in shared files.
Designers and computer programmers are two groups that are
particularly prone to the desire to hold onto their original files and
not provide working copies to others. There are a variety of
rationales for this undesirable behavior that all make sense,
however, the next policy on this list seems to have made a
significant difference in our ability to pry the source files loose
from their cold, dead hands.
Policy: As projects progress to new phases, each team member will
have the right of first choice over whether or not to continue with
One of the possibilities that can arise in interdisciplinary research
is that people decide they would prefer not to work together again.
However, if these decisions are too unilateral or too arbitrary, they
can poison the communication with worry. After we stated that
people can opt out of future phases, but not be fired without
consultation, we suddenly found that many of the reasons for not
providing source files simply disappeared.
Policy: Insofar as ethics clearances allow, data backup will be
provided through central project servers. Local projects should also
make provisions for regular backup of all project files, including
versions of files in progress.
Computer scientists are often quite good at managing files on a
central server, with version control systems and task assignments
that can be tracked toward completion and so on. Other researchers
do not necessarily have experience with these kinds of systems,
and need to be introduced to the idea that the project archives
should be a regular part of the document flow.
4.5 Professional dignity
Principle: We wish to communicate in such a way as to preserve
Human beings like to gossip about each other. They like to
complain behind each other’s backs. Researchers are human
beings, and in these respects no different from other people. By
stating the principle of professional dignity, we hope to encourage
each other to remember that we are working with others who have
a professional standing and who deserve respect as colleagues.
When tempers flare or pressures are felt, this principle can make a
significant difference both in how the situation is discussed and in
the eventual outcome.
We had an example of needing explicit reference to this principle
in a case where we had a disagreement about the leadership of a
subcomponent of one of the projects. The principal investigator and
a team leader were not able to successfully negotiate a series of
tight deadlines, and a change in team leadership was necessary.
The PI had received a number of offline communications from
other team members, and by explicitly invoking this principle and
its policies, we were able to change the team leadership and still
keep a good working relationship with the previous leader, who
remained on the team.
Policy: We will strive to maintain a tone of mutual respect
whenever we write or meet, and to forgive lapses if they occur.
Like professional dignity, mutual respect may be a hard concept to
pin down, but it is relatively straightforward to identify when
people are experiencing a lack of it. As with the other charter
policies, mutual respect is a best practice we hope to maintain,
although in this case we also acknowledge that there may be lapses
that will need to be adjusted if they occur.
Policy: We will attempt to keep communications transparent, for
example, by copying everyone involved in any given discussion,
and by directly addressing with each other any questions or
concerns that may arise.
This policy of transparency is another simplifying strategy. If too
much back-channel discussion takes place, it can become very
difficult for everyone to understand what decisions are being made
and why, especially on a geographically distributed team. It is also
disturbing to see your name appear in an email thread that never
arrived in your inbox, so we feel it is better to err on the side of
receiving too many messages and having the problem of sifting
through them, rather than dividing the communication between
groups. On a typical large research project, we will expect to
receive about 2000 project-related email messages per year.
Principle: We would like to foster goodwill among all the
Enthusiasm and good nature are very beneficial in interdisciplinary
research. Situations will inevitably arise where participants will be
working under pressure or undertaking tasks that are not congenial.
Fostering goodwill can help make the difference, but it requires
attention and commitment. As Bennett and Kidwell (2001) point
out, interdisciplinary research teams are a form of self-designing
work group. Researchers working in this manner always have the
possibility to choose whether or not to make an active effort or to
withhold effort. Withholding effort can have the consequence of
people choosing not to work together again; withholding effort is
also often done for emotional reasons involving the relationships
“…withholding effort occurs in self-designing groups,
such as research collaborations, and that the emotional
bonds that group members form with colleagues play a
key role in whether they decide to work together again,
as well as in how they react to perceptions that a
coauthor withheld effort" (Bennett and Kidwell 2001)
Policy: In making financial decisions, we will attempt to allocate
resources in ways that indicate commitment to each of the people
on the team.
Disputes over the division of financial and other resources can
torpedo a project. A colleague who has served as Department Chair
once described a choice he made that resulted in a successful and
comparatively uncontested allocation of offices. His strategy was to
explain a simple principle that incidentally resulted in him getting
the smallest office. Disputes subsequently just didn’t seem to arise.
Policy: Members will also watch for and notify each other of
opportunities for commercialization and licensing. Any commercial
agreements or plans will be made so as to include and equally
benefit all members of the group.
It is not often the case that commercial benefits are a possibility,
but in some disciplines it is becoming increasingly common to
explicitly address the issue. How this policy may play out in actual
fact remains to be seen, since none of our projects have yet gone on
to commercialization. But we currently have three projects that
have some potential.
Policy: We will strive to be a group working toward different parts
of a larger, coherent and important whole – one that promises to
exceed the sum of its parts.
As with many of our policies, this one might well go without
saying. Yet by articulating it as a policy at the beginning of the
process, we are able to encourage the participants to watch for
opportunities to do more together than they are able to do alone.
For those participants who are used to relying on their own
resources in a research project, the thought of allowing others to be
responsible for some parts of the work does not necessarily come
In addition to being interdisciplinary, many of our project teams are
also inter-institutional, inter-provincial, and international. Canada
is a big country, and an inter-provincial project can involve
researchers who are thousands of kilometers apart. We make use
on different projects of all the various technologies that are
available for meeting at a distance, including project wikis, blogs,
web sites, collaborative online writing tools, Skype, text chats,
conference calls, video conferences, listservs, and email. In a
couple of projects, we’ve recently added an online project
management system, a software version tracker, and a variety of
task assignment tools. These technologies allow us to keep the
projects moving forward. However, we’ve found that for periodic
leaps forward, it is very useful to collect a group of team members
into one location and have them work together for a few days in the
We came across the idea in an anecdote by a colleague, who
described going once to a resort hotel with a friend where the two
of them sat together over a long weekend and co-authored a paper.
Our colleague described it as a very positive experience, so we
determined to see if it would work for us. We have now been
meeting quarterly for the past eighteen months in order to work
this way. We typically rent cluster housing on campus, where four
of us can stay in rooms and share a common working space, or else
we take hotel rooms in the same hotel and commandeer one of the
public areas. Everyone brings a laptop, and we have multiple
people from each role present, so there might be two or three
designers, two or three programmers, a couple of content experts,
and a manager or two. Our experience suggests that it is useful to
have anywhere from 3-5 people. We’ve tried gathering as few as
two, but it is not always possible to get sufficient momentum
going. We’ve also collected together as many as a dozen, but they
subsequently broke into three subgroups.
The purpose of these hackfests is not primarily to hold meetings,
but instead to work together in the same place, where other team
members are available for consultation.
6. CONCLUSIONS & FUTURE
The charter and our related interdisciplinary management
strategies have been developed not only by studying the
management literature, but also through a process of trial and error
on a variety of active research projects. We plan in future to carry
out interviews with team members to see if their experience as they
report it has any correlation to what we believe is going on in these
We are also always on the lookout for additional items to include.
Rockwell (2007), for instance, pointed out the benefit of explicitly
planning for the end of a project, which allows, among other
things, for archiving the materials. Early planning can also result in
the creation of an archival record, not only of the research results,
but also of the research process. Rockwell’s advice is to try to save
the recipe rather than the cake, since technology changes quickly,
and the cake often goes stale. We currently have no principles or
policies related to either project archiving or project closure,
despite the fact that some of our research funding agencies
explicitly request that such archives be created.
We also have additional improvements to make in our quality
assurance methods. For example, Cuneo (2003) recommends
enlisting the help of outside consultants as adjudicators. To this
point, we have relied instead on the reaction of the academic
community, but we recognize that more could be done earlier in the
The authors wish to thank the following organizations for their
research support: the Social Sciences and Humanities Research
Council of Canada, the Natural Sciences and Engineering Research
Council of Canada, the Harriet Winspear Foundation, the Killam
Trust, the Andrew W. Mellon Foundation, the University of
Alberta, and Mount Royal College. We would also like to thank
Lynne Siemens, who introduced us to the idea of the project charter
in her course in Large Project Management at the Digital
Humanities Summer Institute at the University of Victoria .
 Hara, N., Solomon, P., Kim, S.-L. & Sonnenwald, D. H.
(2003) An Emerging View of Scientific Collaboration:
Scientists' Perspectives on Collaboration and Factors that
Impact Collaboration. Journal of the American Society for
Information Science and Technology. 54(10), 952-965.
 SSHRC (Social Sciences and Humanities Research Council of
Canada). (2007). International Collaboration. Retrieved June
30, 2007 from
 Ruecker, S. (2006). “Experimental Interfaces Involving Visual
Grouping During Browsing.” Partnership: the Canadian
Journal of Library and Information Practice and Research .
 Radzikowska, M., Ruecker, S., Fiorentino, C., and Michura,
P. (2007). The Novel as Slot Machine. Paper presented at the
Society for Digital Humanities (SDH/SEMI) conference.
University of Saskatchewan, Saskatoon. May 28-30, 2007.
 Svensson, P. (2003). Interdisciplinary Design Research. In B.
Laurel (Ed.), Design Research: Methods and Perspectives
(193-200). Cambridge, Mass.: MIT Press.
 Amabile, T. M., Patterson, C., Mueller, J., Wojcik, T.,
Odomirok, P. W., Marsh, M. & Kramer, S. J. (2001).
Academic-Practitioner Collaboration in Management
Research: A Case of Cross-Profession Collaboration. Academy
of Management Journal, 44(2), 418-431.
 Wynne, S., Ruecker, S., Nelson, T.M., Albakry, W., Strong,
M., Lewcio, M., and Plouffe, M. (2007). The rich prospect of
tension, affiliation and reward: from social capital to image
analysis. Paper presented at the Society for Digital
Humanities (SDH/SEMI) conference. University of
Saskatchewan, Saskatoon. May 28-30, 2007.
 Zimmerman, E. (2003). Play as Research: The iterative design
process. In B. Laurel (Ed.), Design Research: Methods and
Perspectives (176-184). Cambridge, Mass.: MIT Press.
 Bennett, N. & Kidwell Jr., R. E. (2001). The Provision of
Effort in Self-Designing Work Groups: The Case of
Collaborative Research. Small Group Research, 32(6), 727-
 Rockwell, G. and Johnson, N. (2007). The Globalization
Compendium: Reflecting on Contemporary Research and
Online Publication. Paper presented at the Society for Digital
Humanities (SDH/SEMI) conference. University of
Saskatchewan, Saskatoon. May 28-30, 2007.
 Cuneo, C. (2003). Interdisciplinary Teams - Let's Make Them
Work. University Affairs. 1(1).
 Sillitoe, P. Interdisciplinary Experiences: Working with
Indigenous Knowledge in Development. Interdisciplinary
Science Revi ews, 29,1, (Marc h 2004), 6- 23.
 Schuler, D, & Clement, A. (2004). Artful integration and
participatory design: Preface to the proceedings of PDC 2004.
In Clement, A., van den Besselaar, P. (Eds.), Proceedings of
the Eighth Conference on Participatory Design (1st ed., pp. v-
vi). New York, NY: ACM Press.
 Hobson, S. (nd) Case Studies in Gerontology for the Applied
Health Sciences. Retrieved July 17, 2007, from
 Wilson, V and Pirrie, A. (2000). Multidisciplinary
Teamworking Indicators of Good Practice. The Scottish
Council for Research in Education Research Report, 77.
 Zhang, S., Zhao, C., Zhang, Q, Su, H., Guo, H., Cui, J., Pan,
Y. and Moody, P. (2007). Managing Collaborative Activities
in Project Management. Proceedings of the 2007 symposium
on Computer Human Interaction for the Management of
Information Technology (CHIMIT '07). March 30–31, 2007.
 Seipel, M. (2005). Interdisciplinarity: An Introduction.
Retrieved July 22, 2007, from
 Keil, M., Smith, J., Pawlowski, S. and Jin, L. (2004). Why
Didn't Somebody Tell Me?: Climate, information asymmetry,
and bad news about troubled projects. ACM SIGMIS
Database, 35(2), 65-84.