Notes for Presentation on Project Management
Getty Institute, July 26, 2014
SLIDE 1.
You manage projects all the time. You’ve written books, some of you manage art
galleries or library collections — can you not just use common sense to manage DH
projects as well?
OK TO RELY ON COMMON SENSE
BUT THERE IS A USEFUL BODY OF KNOWLEDGE
VERY BASICS
GENERAL PRINCIPLES
RESOURCES
20-25 MINUTES + DISCUSSION
URL
SLIDE 2.
PROJECTS IN DH
PROJECT AS BASIC UNIT OF ANALYSIS
AMBITIOUS, COMPLEX
IS THAT WISE?
Of course, we’ve been complicit in this by asking you to have a project in mind for
this institute. We’ve done that because we’ve found that people learn best when
they’re applying concepts and techniques to things they can imagine themselves
doing.
But we wouldn’t ask someone who’s new to filmmaking, for example, to
immediately take on a directorship. In a similar vein, I’d like very much to encourage
you to think about digital humanities not as the thing that will help you to
accomplish one massive project, but as a set of ideas, tools, and techniques that
you’ll bring to bear in the service of a much longer intellectual career.
It is perfectly reasonable and legitimate and laudable to start slowly and build a set
of interests and skills over a long and varied career. To put this in concrete terms, it
is perfectly reasonable to think in terms of a web-based map to complement an
article, rather than a massive portal that will subsume all the scholarship in your
field.
So having said that, I’ll move on to the actual pragmatics of working on a project.
SLIDE 3.
I have seen a lot of DH projects crash and burn. I think all of us in here have. The
first thing to say about that is that that’s OK. It’s perfectly OK to start working on
something and realize, you know, this isn’t going to work out for me. It’s not what I
thought it would be.
But sometimes projects don’t have to crash and burn and they do anyway, despite
everyone’s best intentions. In my experience, this seems to happen for a few
reasons:
BULLET POINT 4.
The sponsor pulls out. And by “sponsor” I don’t mean the person who’s putting up
the money, necessarily — I mean the person whose idea it was in the first place.
This happens most commonly when the sponsor is a faculty member. They realize
this is going to take way more time than they thought and be way more of a hassle,
and they just stop replying to emails.
BULLET POINT 5.
Two: We didn’t really know what we were doing. Some people thought we were
doing one thing, other people thought we were doing something else, we were
working at cross purposes and everyone got annoyed with everyone else.
BULLET POINT 6.
Three: We hadn’t worked out copyright issues fully. I’ll say more about this in a
minute, but copyright issues can be really time-consuming, and they can stop a
project in its tracks.
BULLET POINT 7.
And finally, someone has to keep their hand on the wheel at all times. Projects’
natural tendency is to slowly diffuse into nothingness — especially if there are a few
people working on them. Someone needs to be the driver, who pushes things along
and makes sure things are going according to schedule.
So how do we mitigate against these risks.
SLIDE 8.
We can start by assembling a good team. There’s a longer conversation to be had
about how to assemble a good team, but one rule of thumb is that you need to start
building a team when the deliverables are beyond your ability to complete. I
recommend keeping a team small at the start and adding to it as needed. Ideally,
everyone on the team will have an incentive to participate in the project, whether
it’s a professional credential or payment. Projects that depend solely on someone’s
goodwill are on very shaky ground.
It’s really important — crucial — that you treat them as peers and not service
providers. They have a body of knowledge that’s different from yours but vital to
what you’re doing. It’s not like Kinko’s, where you drop stuff off and pick it up when
it’s done; you have to be responsive, forthcoming, and generous.
This question of how to credit collaborators is something that’s come up a lot in
digital humanities. I’d encourage you to look at the Collaborators’ Bill of Rights
SLIDE 9.
which was developed to help digital humanities scholars sort out these questions. It
deals with things like how to credit collaborators on your website, who can list this
stuff on their CV, that kind of thing. I can tell you that it’s very bad practice — and
we notice — when a scholar is heralded for her pioneering DH work but doesn’t
credit the technologist or grad student or librarian who worked with her.
SLIDE 10.
Your project really should have a project manager. This is a person whose job it is to
check progress against a schedule, run meetings, handle communication, and check
to make sure everyone’s feeling OK about their workload. Fine to designate yourself
PM, but that means you’ve committed to taking on this body of tasks.
The project manager is not the enforcer. When a problem arises — say someone
doesn’t turn something in that they said they would — the project manager doesn’t
punish the culprit. The project manager says, “OK, how should we modify our
schedule in response?”
This approach has some really healthy effects on the team as a whole, because it
encourages the team to take ownership of the project, not assume it’s someone
else’s baby. It also helps to curtail the sense of panic that can arise on any project
when a deadline nears and something problematic comes up. If a problem happens,
it’s not a crisis. It just means we alter the plan in response.
SLIDE 11.
So how do you alter your plan in response to a problem? Well, if the total size of this
triangle represents the quality of your project, you can’t alter one node without
altering another. That’s a basic principle of project management.
So say you realize that an important conference is coming up and it would be
amazing to have a prototype of your project ready to show. That’s fine. It just means
that, because you’re decreasing the time to completion, you have one of two options.
You can increase the cost of the project — say, hiring an extra developer to get it
done — or you can change the scope of the project, making it more modest in its
ambitions.
It’s not a crisis — it just means you have to modify the plan.
SLIDE 12.
All this suggests that you have a plan in the first place. It’s really important to get
things down on paper when you’re working with other people, even — or especially
if — you think everyone is on the same page. Within project management,
documentation can take many, many forms, from the simple to the incredibly
elaborate.
For most projects, I favor what’s called “the project one-pager,”
SLIDE 13.
which is an idea developed by Tito Sierra, who’s now at EBSCO. The idea is that you
get your team members together to collaboratively agree on some basic parameters
of the project. Some of these seem really obvious — like, why do you need to give
the project a name? — but you’ll be surprised at how different people’s ideas of
what they’re doing can be, once they’re asked to lay their assumptions bare.
Helpful to ask what’s off the table.
It’s important to know that this project one-pager can change. There’s no reason to
stick to something stupid just because it’s on paper. I recommend pulling up the
document from time to time and reviewing it with the group. “Do we still think
we’re doing the same thing? Do we still think we can get it done when we say we
will?”
If you’re working with other entities, like campus IT groups or vendors, you may
want to consider more formal documentation — things like memoranda of
understanding or service-level agreements, which are really just other ways people
put their expectations in writing.
SLIDE 14.
Duke’s Office of Information Technology has a repository of templates for these
kinds of agreements. Some of them are intimidatingly complex, but it’s a good thing
to check out if you want to see the most formal level of project documentation.
SLIDE 15.
Once you’ve agreed on expectations, you want to set up regular team meetings.
Email is no substitute for face-to-face meetings, and neither is project-management
software. You have to see each other and iron out understandings. Even if you’re
busy. If the project is a priority, you have to do it.
Most common reason DH projects fail is that the faculty member loses interest.
I like to set up recurring meetings, with the understanding that we can cancel them
if we don’t feel they’re necessary. How often you should meet depends on the
project. I would put the question to the team: How often is useful for us? How often
is too often? Then you can revisit the question periodically.
It’s important to know that it is not necessary — in fact it’s a waste of time — to
hold too many meetings with everyone on the team. It’s great to be democratic and
transparent, but it’s also inefficient to require the presence of people who don’t
need to be there.
I like to have “working meetings,” or “worksessions,” or “hackathons,” where
everyone gets together in one place — preferably with food and music — for a few
hours and works away in proximity to each other. This is also a great way to form
bonds as a team.
Obviously, we’ve all sat in enough meetings that we think we know how they work.
But there are in fact some very simple principles for running meetings that can
make things go a lot more smoothly — things like agreeing on ground rules and
checking in.
SLIDE 16.
If it doesn’t feel too absurd to you, you might dip into the literature on running
effective meetings — some of the tips really do help. And I’ve found that these
techniques have also been useful in my teaching.
SLIDE 17.
In general, we’ve found that because people don’t see the back end of projects — the
data they’re built on — they get focused on the shiny, eye-catching things, like
having a rotating image carousel or a really cool map. But having the right data will
make or break your project, and gathering it, structuring it, and cleaning it takes a
really long time. You should plan to spend a great deal of your own time just
gathering and collating sources.
Again, this is one of the most common reasons DH projects break down.
SLIDE 18.
For example, it would be easy to focus on this cool network diagram of the Getty
Provenance Index, because that’s .… what you see! But, as Christian Heumer is going
to explain tomorrow, each node on this diagram comes from a physical source and
had to be extracted, parsed, cleaned, and structured. That’s the real work of this
project, not the cool network diagram. If you don’t have your data, you just can’t
make progress.
SLIDE 19.
It’s also important to start thinking about copyright early on. Why do so many
digital projects deal with a historical period before 1923? Because that’s when stuff
stops being in the public domain. You’ve probably dealt with copyright in some form
before, with publications. But you’ll probably be dealing with a lot more stuff now,
and a lot more images, and my best advice on this is to get some expert help. I would
start with your librarian. Most librarians are well-versed in scholarly
communication and intellectual property issues or can refer you to someone who is.
SLIDE 20.
However, I do want to say a word or two about fair use .…
SLIDE 21.
Quote from CAA report
SLIDE 22.
So I’ll end there for now. If you’re interested in knowing more about project
management, there’s a lot of really bad writing out there. These are the resources I
recommend, and of course I’ve linked to them from the document I shared with you.