Below are my notes from a Digital Humanities workshop I attended yesterday evening on project management. I was surprised by how specific and detailed the workshop was, and was encouraged to learn that the Digital Humanities are beginning to adapt the standards and language of business-oriented project management to suit the specific needs and aims of DH. Thank you to UNL Center for Digital Research in the Humanities’ (CDRH) Liz Lorang for putting this great workshop together.

Project Management for Digital Humanities
2.18.2014

Projects…

• are unique/produce a unique result
• have a defined scope
• have a defined start and end
• must be completed with set resources

• useful to drive this^ definition home → can’t successfully manage the project if don’t have a clear, defined understanding of the above

Project management = “the application of strategies and methods to complete projects effectively and successfully”

• a successful project…is completed on time and with the agreed upon resources; produces product deliverables and meets scope and quality requirements
• NOT about exceeding expectations →if scope of project and expectations continue to expand, may not get the original project, idea completed

• DHers working more in teams, need to be able to run projects effectively (esp. to get and justify funding)
  • when introducing more variables into a project, need a project manager to ensure project is progressing, goals are being met
  • projects are often looking for project managers → good way for graduate students to get good experience & translate this for your own projects
    • most often, the person behind the project idea = NOT the project manager
    • skills gap between DH folks who have great project ideas but don’t have time or resources to be able to do the management portion of this

• there are many different types of project management
  • much of the language, materials on how-to manage projects = dealing with a specific business culture → not always related to DH concerns, standards, methods
  • e.g. “lean” project management = all about maximizing efficiency, use of resources, most “bang for the buck”
  • traditional, adaptive, discovery, extreme = the 4 primary types of project management
    • DH @ UNL sees quite a bit of traditional & adaptive

• So what’s the right method?
  • goals, project activities → if BOTH = clearly defined, traditional = the way to go
    • if NOT clearly defined, adaptive may be more the way to go
  • not all projects will be managed the same way
  • across both methods (traditional, adaptive):
    • every project should have: defined goals, deliverables, scope, start & end dates, defined team & roles, defined stakeholders, defined resources
    • AND every project must include: initiating, planning, executing, monitoring/controlling, closing
    • BUT methods look different in practice
  • sometimes funding applications (e.g.) NEH funding application becomes the “founding document” BUT, often, things will change → and IF goals, definitions change, it is best for the sake of the project to write up all of the above^ very early on

• traditional project management in practice = initiate → plan → execute → monitor → close
• agile/iterative project management in practice = initiate → plan → execute → monitor → [repeat: plan → execute → monitor] → close
  • e.g. Whitman Archive standards need updated → need to explore first in order to determine what need to accomplish and how long it will take (won’t be a linear process: “code sprints” = work intensely on one problem for a week, then move on to the next problem)
  • e.g. DH practicum course being offered this semester: encourage students to set 3-hour goals as a way to begin exploring problems and risks, “real world” goals for solving problems

• the CDRH uses a “charter form” for the initiate phase → Liz to share a copy with workshop attendees

Project charter:

• Vision (Why? What question(s) are you answering?)
• Mission (What?)
• Success criteria (How will we know if the project is successful?)

• Where and how the above^ is documented varies from one project to another, depending on who you work with, how big and/or formal the project team is
• not the role of the project manager to create these things (although will be involved in this process), but need to be sure these things are articulated as early as possible
• if mission/success criteria changes, need to determine the impact on the project → e.g. will the deadline(s) for the project, budget, goals also change?
• more traditional models may also specify the following in their project charter:
  • sponsor & stakeholders
  • roles
  • assumptions & constraints working under
  • standards (e.g. thematic research collection, documenting what encoding standards you are using → this can be important to state in the early stages if, for example, you are farming out some of the work and/or if some members of the team don’t have a lot of technical knowledge)
  • budget (monetary as well as time budgets can be useful)
  • schedule (short-term project: month-by-month…)
  • milestones
• really expansive project charters don’t tend to work well for academic projects
  • risk plan (known risks, possibilities for some unknowns – want to have contingency plans)
  • communication plan (sounds great in theory, but may not pan out in academic culture → various plans for breakdowns in communication) (BUT probably works well in class projects, when at a peer-level with members of the project)
  • work breakdown structure (often assume “chart-like” form, ascending/descending tasks, how tasks relate to one another, identify critical pathways, things that must be done in order for next step to be done)

Open discussion:

• a lot of DH management is being done by women
• Project Management Institute = basically has a monopoly on the certification in project management professional
  • DHSI & HILT have offered project management courses in the past BUT not yet wholly geared toward DH (still using a lot of approaches and language from business)
• various types of software for delegating responsibilities?
  • Trac = used @ the CDRH for several projects & has worked well → can set milestones & see a roadmap
    • ALSO great way to keep track of who’s working on what (especially important for large projects), keep everyone updated on progress of project, document key decisions…
  • Asana = something one of the workshop attendees has used → it was “overkill”, things pile up, is very business-oriented
  • Basecamp = another option, not much experience using it in the room (it’s not open-access)
• communications aspect may be one of the most difficult aspects of project management, especially when the project manager isn’t necessarily on equal footing with the members of the team