Humanities & Technology: Lightweight Project Management
Delphine KhannaTHATCamp Philly Sep. 23, 2011
Who am I?Delphine KhannaCurrently Head of Digital Library
Initiatives at Temple UniversityPreviously Digital Projects
Librarian at the University of Pennsylvania
Who are you?Who has been involved in a
collaborative H&T team project?◦Above 5 people, under 5?
Name, Job title, InstitutionExample of a Humanities &
Technology project you have been/will be involved in
What is this workshop about?Getting a bunch of human beings
together to get a project done◦Presents a number of challenges
What are some of the skills, techniques, and tools that can help you do that?◦Without becoming too much overhead◦Just a little bit can go a long way to
make your project successful
Why am I teaching this workshop?I have managed/participated in many,
many collaborative projectsMethod grown over the years, through
formal training and trial and errorStrong interest in project management
◦Co-founder of Project Managers’ Group at the Digital Library Federation Forum
Inspired by Agile / Scrum◦PM framework for faster, more flexible
development Used a lot for software/web development
◦But not at all applied to the letter
On what kind of projects do I work? Develop web sites and web-based applications
◦ Delivering special collections or archival materials◦ Sometimes working with faculty and researchers◦ Often involving a wide realm of participants (both intra- and
cross- institutions). Some examples
◦ Collection of digitized South Asian architectural photographs◦ Collection of digitized medieval manuscripts◦ OLAC Language Resource Catalog◦ Catalog of Special Collections finding aids for the Philadelphia
area◦ Archival collection website illustrating Civil Rights in Philadelphia
Should be widely applicable to a variety of Humanities & Technology projects◦ But my examples are somewhat biased toward web-based
projects
How will this workshop be organized?
Overview of what I personally feel is essential to manage projects in our realm
A few hands-on exercisesSome time for questions and
discussionHopefully a lot of practical information
you can take back with you and put into practice
If I mention an issue, it is because I have seen it be a problem in many projects
Assumptions/NotesYou are involved in some Humanities
& Technology activities/projectsYou are pretty conversant with usual
web technologies and tools.◦E.g., I will not detail how to use Google
Docs, or SkypeBut I will stay around to answer
questions◦I will be glad to show you how specific
tools work
OutlineIs project management really useful?Lightweight project management toolsGroup meetingsStart of a project: know where you are
going◦List of features/user stories & feature ranking
When is the project done?◦Project phases / release dates / feature creep
Actionable to-do listsTime boxingTeam dynamics
What issues have you encountered with collaborative DH projects?
What went wrong? What were the challenges?
Is project management really useful? Yes!To know where the project is goingTo make sure the project gets released
◦ Does not get horribly delayed or forever in development◦ Does not get abandoned somewhere along the way
To make sure that all the stakeholders are happy with the finished product◦ And to make sure the team members don’t hate each
other by the end of the project ;-)But keep project management light weight.
◦ Unless your project is really large Heavy duty project management is usually an overkill in our
field◦ Minimize the overhead
Lightweight project management toolsMany tools out there
◦Don’t hesitate to try a few outGoogle Docs spreadsheetBasecamp is another possibilityMicrosoft Project is not for
lightweight project management
Google Spreadsheet to-do list Heart of the project
◦ Expresses exact status at any point in time◦ Constantly go back to it
I have been using that tool for several years now.◦ Very simple, very low overhead◦ It just works
I am not paid by Google to say that! ;-) Very simple, non threatening
◦ Everyone knows how to use a spreadsheet◦ Unlike tools like Jira
Can be intimidating for non programmers
Greatly collaborative◦ Can have several concurrent editors◦ Version control◦ Avoids multiple versions in email attachments
Which one is the most up to date?
Google Spreadsheet to-do listExample: OLAC Language
Resources Catalog◦Many possible variations on their
specific columns Whatever works for the group
◦In this case What, Who, Status, Description/Comments, Priority points, Date raised, URL
Google Spreadsheet to-do list Be very systematic in using the to-do list
◦ Go through it at each meeting It provides a natural structure for the meeting
◦ No to-do should be outside of the to-do list Especially no to-do’s lost in someone’s mailbox
◦ Nothing falls through the cracks◦ You see exactly what is left to be done◦ People are held accountable
Each item should get assigned to a specific individual (or a small set of them)
If possible with a priority level or a target date for completion Decided along the way
◦ Try to record updates and decisions right during the meeting◦ Serves also as minutes
Very low overhead “Done” Tab
◦ You can also add several other tabs with any supplementary information useful to the project
Group meetings
Regular ◦ Weekly? Biweekly? Monthly?◦ Should not be too spaced out
Otherwise you loose the momentum◦ Recurring meetings
Don’t waste time looking for a new time slot each timeAt each meeting, go through the to-do list.
◦ Everybody should be able to look at the spreadsheet◦ Big monitor in meeting room, or individual
laptops/tablets
Group meetings
Virtual meetings◦ If you can’t be all in the same location◦ Meeting through Skype (or equivalent).
Very efficient: Voice + Google Spreadsheet + Site prototype
I have been on projects entirely run that way It really works.
◦ If possible try to meet in person: At least once at the beginning of the project When there are complicated/touchy issues to be sorted
out◦ Useful even if people are not very far from each
other (e.g., greater Philadelphia) Once every 2 meetings?
Start of a project: know where you are going
Step 1: get agreement on what the goals are◦ Short “Mission statement”
Step 2: create list of deliverables / features◦ “Requirements gathering” in traditional project management◦ Many techniques to do this
This could be a whole other workshop◦ One method: asking people to come up with “user stories”
One-sentence narrative describing how someone would use the web site [or other project outcome], what they would be able to do with it.
Used in the Agile PM approach◦ Example: Cooking Recipe site
As a user, I want to browse the recipes by cuisine/country of origin As a user, I want to rate a recipe by giving a number of stars As recipe submitter, I want to add new recipes through a form As a content manager, I want to review newly submitted recipes, and
check that the content is appropriate
Start of a project: know where you are going
List of features: brainstorm with the team◦You might want to add other stakeholders
for this step◦List features in no special order
Really important even if you can’t go into all the details◦To know what the project is really about
Flesh it out◦To make sure that all team members are
more or less on the same page
Feature ranking
Trying to implement all the features at once◦ Very dangerous
The project risks to be very very long◦ And never get released
Rank desirability of each deliverable/feature◦ Not all features are equal
Some are more essential than others Some are just bells and whistles
◦ Really essential to recognize that So that you can define what the core project really is
→ You want a ranked list of features Ranking a list of features could take a long time
◦ Can be debated to death, every team member having their favorites, etc.
◦ Speeding up the process: Agile-style ranking method
Agile-style ranking method
Somewhat simplified version Explain to the group that the goal is to obtain a rough
ranking, not a perfect one For each item:
◦ Vote 1-5 1= lowest desirability; 5=highest desirability
◦ Can you agree on a number?◦ If not: 5 minutes of discussion per item
Make it fun, use an online hourglass, with cool gong sound at the end.
◦ Vote again Can you agree on a number? If not move on to next item
At the end, just sort your spreadsheet◦ If some items could not get a number, you can do one
more round just focusing on those.◦ Et voilà! Good enough in 95% of the cases
When is the project done?
Goals for the project release
Don’t say: “we will release the project when all the features are developed and everything is perfect”◦ That project will never end◦ Or at least it will take a very very long time
Instead say:◦ “We will release the project as soon as we have developed
the core features that will make the site reasonably useful to its users”
◦ “We will add more bells and whistles later.” Having ranked the features will make it much easier
to distinguish core features from less essential features
Note: this has become the norm out there:◦ Put out a basic Web site, and improve it over time
Facebook, Google apps, etc.
Project phases
Slice up the project into achievable chunks = project phases◦ Phase 1 = the highest priority features◦ Phase 2 = second tier◦ Phase 3 = last tier
First release: work on Phase 1 and go live◦ Even if you don’t know when Phase 2 and 3 will
happen◦ Choose a release date for Phase 1 and (try to)
stick to it.◦ Your lower Phase 1 items might need to be moved
to Phase 2 If you are running late
Project phases
After the first release, you can move to Phase 2◦Proceed just like for Phase 1◦Choose a release date◦If you’re getting late you might need
to move the lowest ranked Phase 2 items to Phase 3
You can put a gap between phases◦So that team members can focus on
other projects, their day job, etc.
Scope creep“Couldn’t we add this feature?”
“And what about that one?”Very dangerous
◦The project never endsAvoid scope creep with Feature
ranking and Phases◦If someone comes up with a new idea
in the middle of the Phase 1: put it in Phase 2 This is best trick ever
Feature ranking and Phases: bottom lineIt is OK to have lower ranked items
that never get implemented◦You may or may not get to Phase 2 & 3
Based on funding, time, etc.◦But that’s ok because you have already
implemented all the essential features.It is not OK to have a project never
go live because of ◦Endless lists of features and◦Scope creep
Actionable to-do list
Turn the list of Phase 1 features into an actionable to-do list ◦ More or less “Specifications” in traditional project
management In some PM approaches, the team works directly
with the list of user stories/featuresBut in practice, and depending on the project
◦ It will usually be more convenient to break down things into more specific to-do’s
◦ E.g., As a user, I want to consult a glossary of ingredients To-do 1: Develop database structure for glossary To-do 2: Enter actual entries in database → Different people will be assigned to each task. → They might be done at different times, etc.
Actionable to-do list
Also there will be some basic to-do’s that do not correspond to a user story◦ To do 1: Get a server set up◦ To do 2: Deploy basic Omeka instance on server
And all kinds of small to-do’s will be added over time:◦ Bug fixing◦ Fine tuning of features◦ See OLAC example
Before you start working on your Phase 1, you must have a list of “to-do’s” for your Phase 1 that is◦ Actionable◦ Ranked◦ Realistic
Time boxingEndless discussions within the team
can really slow down a projectDiscussing an issue to death will
not necessarily lead to a better decision
Time boxing: limit discussion time to a certain length
A few cases to be particularly careful about
Red flag #1: obsessing over details
◦Fine points of detail that end-users will really not care about. “Should we call this button ‘Go’, ‘Search’, or
‘Find’?”◦Time box the discussion
E.g., 5 minutes◦And take a temporary decision
Say that if during the testing phase, this seems to be an issue, the group will revisit the decision.
◦95% of the time the temporary decision turns out to be just fine
Red flag #2: very theoretical and lengthy debates
Some of it is useful, especially at the beginning to define the goals and scope of the project.
But beyond a certain point, it just makes the project stall.◦ E.g., “Should we use truly exact/scholarly terminology on
our site, or more common language that more users will understand?”
Time box it◦ Acknowledge the problem◦ 30 minutes? 1 hour? depending on the seriousness of the
issue◦ With the goal of finding a concrete way to move forward◦ People might have to agree to disagree.
A vote might be useful (majority rules) Be practical.
Red flag #3: ranking long lists of items
That can take for everExamples:
◦List of desired features for a web site See exercise on Cooking Recipe site
◦List of possible collections that could be digitized and published on the web
◦List of possible scholarly topics that could be addressed on a thematic web site
Agile ranking method: ◦Rough results but good enough in 95% of
the case
Time boxing: to summarize
◦Be on the lookout for discussions that start dragging on
◦And propose a time boxing solution
Team dynamicsDealing well with team dynamics
◦Soft skills◦But essential part of project
management◦There is a whole theory of team
dynamics We will look only at a few crucial points
Be realistic about team work◦Can be hugely rewarding◦But also presents its share of
complexities
Team dynamics: expect sub-cultures, and difference of perspectivesPeople’s jobs/ roles
◦Humanist/Technologist◦Librarians: Cataloger/Public Services
Librarian◦Different academic fields
Generational gap◦Esp. regarding digital technologies
Within a single institution◦Different units
Team dynamics: expect sub-cultures, and difference of perspectivesOf course even more true across institutions
◦ Different conception of time “Let’s try to do X quickly”: what does that mean?
◦ Different levels of red tape◦ Different levels of resources
E.g., getting some help from the IT department◦ Different level of availability
“I have some time for this project”: what does that mean?
◦ More generally, different ways of doing things / thinking about things
Expect the differences, and embrace them as a natural phenomenon
Team dynamics: expect differences of opinionConstantly try to put yourself in each team
member’s shoes.Try to understand:
◦ Where are they coming from What they are bringing to the table, their expertise
◦ Their concerns/points of resistance The reasons for those
◦ They are highly trained professionals, they probably have a good reason to have a specific opinion Even if it clashes with yours Even if they don’t have the most diplomatic way of
expressing it Try to look beyond the aggressivity or lack of diplomatic
skills To understand their perspective
As a team leader, when a difference of opinion arisesKeep the group focused on the project’s
outcome ◦To move beyond those differences and keep the
project moving forwardKeep looking for commonalities and
middleground solutionsKeep looking for a common language, be a
translator ◦E.g., Humanist vs. Technologist
Make sure everybody has a voice, help articulate everybody’s point, keep the dialog balanced.
Team dynamics: expect ups and downsA project is a very dynamic
processPeriods of
◦Enthusiasm◦Great productivity◦Crisis◦Stress◦Discouragement
Team dynamics: expect ups and downs A few potential downs:
◦ The project stalls due to strong disagreement on a key issue◦ Lack of progress due to external factors
E.g., the IT department cannot provide the server needed◦ Unforeseen obstacles
E.g., a piece of software was supposed to fulfill a specific need, but it turns out that it does not have this capability after all
◦ The deadline is fast approaching and there is still so much more to do
◦ Some team member has suddenly much less availability Ups and downs are normal
◦ What’s important is to keep going, staying focused on the goals
Make sure to celebrate milestones
Time dynamics: to summarize
Expect conflictsExpect periods of stress and
discouragementAll those are natural and do not
mean that the team is malfunctioning
Just keep going
Team leader vs. team influencerYou don’t have to be the official team leader to
help with the management of a projectAttitude is everything
◦ Help the team stay focused on the positive, moving forward, communicating well
Be a translator, help people find a common language
Propose tools and ways of doing things (to-do list, etc.)◦ Magic words “Maybe we could try...”, “Let’s do this as
an experiment” If people notice that you usually help move things
forward, they will listen to your recommendations
To learn moreWorkshops/books/articles on:
◦ Agile project management (not necessarily Scrum)
Generic project management◦Caution with project management
courses and books that are very corporate oriented
Working in Teams◦Pick and choose, you don’t have to
apply a method to the letter.
A few booksCook, Curtis R. Just enough project
management: the indispensable four-step process for managing a project better, faster, cheaper. McGraw-Hill: New york, 2005.
Berkun, Scott. Making things happen: mastering project management. O’Reilly Media: Farnham, 2008.
Cohn, Mike. Agile Estimating and Planning. Prentice Hall: Upper Saddle River, NJ, 2006.