Who am I? Delphine Khanna Currently Head of Digital Library Initiatives at Temple University Previously 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, Institution Example 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 projects Method grown over the years, through formal training and trial and error Strong 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 exercises Some time for questions and discussion Hopefully 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/Notes You are involved in some Humanities & Technology activities/projects You are pretty conversant with usual web technologies and tools. ◦ E.g., I will not detail how to use Google Docs, or Skype But I will stay around to answer questions ◦ I will be glad to show you how specific tools work
Outline Is project management really useful? Lightweight project management tools Group meetings Start 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 lists Time boxing Team 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 going To 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 tools Many tools out there ◦ Don’t hesitate to try a few out Google Docs spreadsheet Basecamp is another possibility Microsoft 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 attachments Which one is the most up to date?
Google Spreadsheet to-do list Example: 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 time At 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? 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 ends Avoid 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 line It 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/features But 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 boxing Endless discussions within the team can really slow down a project Discussing 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 ever Examples: ◦ 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 dynamics Dealing 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 perspectives People’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 perspectives Of 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 opinion Constantly 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 arises Keep the group focused on the project’s outcome ◦ To move beyond those differences and keep the project moving forward Keep looking for commonalities and middleground solutions Keep 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 downs A project is a very dynamic process Periods 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 conflicts Expect periods of stress and discouragement All those are natural and do not mean that the team is malfunctioning Just keep going
Team leader vs. team influencer You don’t have to be the official team leader to help with the management of a project Attitude 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 more Workshops/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 books Cook, Curtis R. Just enough project management: the indispensable four-step process for managing a project better, faster, cheaper. McGraw-Hill: New york, Berkun, Scott. Making things happen: mastering project management. O’Reilly Media: Farnham, Cohn, Mike. Agile Estimating and Planning. Prentice Hall: Upper Saddle River, NJ, 2006.