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.

Questions? Comments?

delphine@temple.eduThanks!