Lightweight Project Management Workshop in Humanities & Technology

1. Humanities & Technology: Lightweight Project Management DelphineKhannaTHATCamp Philly Sep. 23, 2011

2. Who am I? • DelphineKhanna • Currently Head of Digital Library Initiatives at Temple University • Previously Digital Projects Librarian at the University of Pennsylvania

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. What issues have you encountered with collaborative DH projects? • What went wrong? What were the challenges?

11. 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

12. 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

13. 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?

14. 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

15. 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

16. 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

17. 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? 

18. 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

19. 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

20. 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

21. 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

22. When is the project done?

23. 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.

24. 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

25. 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.

26. Scope creep • “Couldn’t we add this feature?”“And what about that one?” • Very dangerous • The project never ends • Avoid scope creep withFeature 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

27. 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

28. 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.

29. 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

30. 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

31. 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

32. 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.

33. 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

34. Time boxing: to summarize • Be on the lookout for discussions that start dragging on • And propose a time boxing solution

35. 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

36. 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

37. 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

38. 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 aggressivityor lack of diplomatic skills • To understand their perspective

39. 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.

40. Team dynamics: expect ups and downs • A project is a very dynamic process • Periods of • Enthusiasm • Great productivity • Crisis • Stress • Discouragement

41. 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

42. 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

43. 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

44. 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.

45. 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, 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.

46. Questions? Comments? • delphine@temple.edu • Thanks!