While I was at THATCamp DHSoCal last weekend, I heard numerous attendees refer disparagingly to their “IT Guy” or “those guys at IT.” The references made me uncomfortable because I am an affiliate of IS&T at Chapman (and I’m not a “guy”) and because the term was generally used to indicate staff who are unhelpful and uninclined academically. The term “IT Guy” often appeared in the same sentence as “Blackboard” to compound the insult.
Apart from my concern that Chapman faculty might feel negatively about me or others from my Office because of our IT role, this trend of dissing IT staff is especially disconcerting for those of us who inhabit the Digital Humanities. Because, for our projects to be both attainable and sustainable we very much need IT support and resources. Disparaging (or dehumanizing) those who have technical roles at the university can only widen gaps that might already exist in the organizational structure of our campuses, and thereby reinforce barriers to team-building and project progress.
Perhaps I am particularly sensitive to this issue given that I’ve worked so hard over that past four years at Chapman to gain the trust of faculty and staff. That work has included my attempt to speak and write in ways that don’t alienate others by using technical jargon or assuming a certain level of academ-ese. Also, I purposefully refer to IT staff by their names, roles, and/or titles rather than as the generic “IT guy” (just as I do when I discuss faculty or administrators).*
Because, while the divides between “operations” and “academics” are undoubtedly deep at many campuses, that does not mean that there should not be efforts to effect change, and using inclusive language to describe our colleagues is one big step towards doing so.
*at Chapman we have a CIO who is a woman, about half of IT directors are women, and many of the affiliated technical staff are also women–I suspect that it is a rare IT division that does not include many women.
I’m sitting at the food court at UCLA and I feel like a student again. Which I am, because I’m on campus for a two-day intensive training in Project Management from UVic professor Lynne Siemens. Usually taught in a week in the summer at the DHSI, we’ve moved quickly though the 450 page(!) manual prepared by our instructor.
Perhaps the most important take-away message from this event is realizing how integral Project Management has become for the kinds of team-based projects that are common in the Digital Humanities. From this class I’ve gained skills that I intend to add to my DH-class syllabus and that I will share with my faculty colleagues. But most importantly, I’ve learned concrete steps for project planning that I’ll apply in nearly every aspect of my own work–as an administrator, a researcher, and (most importantly) as a grant-writer.
While many of the steps that we learned are intuitive–defining the nature of our research questions and the expected outcomes, listing each step of the process, creating workflows for accomplishing phrases of a project, etc.–some elements were less intuitive, such as finding a critical path through a project, defining the scope clearly and balancing that against the time and money allocated for the project, adding moments within the plan to evaluate whether it’s still achievable, and creating a shared documentation system for recording all aspects of a project.
After having spent the last two days steeped in PM, I must confess that it’s not the most exciting topic imaginable. In fact, it can tend towards being self-evident (well, of course one needs to plan incremental deadlines in order to pull all of the pieces together for a large project to reach completion on time). But…the more I followed all of the processes and considered how they could be applied to just about anything: writing a journal article, planning a conference, coordinating volunteer writers for a group blog, etc., the more I realized that applying the elements of PM are critical for seeing projects through to completion. Because it seems as though (at least for me) projects are always so very easy to start, but so very difficult to finish.
I’m a sucker for productivity tips, and was just reading yet-another article in this vein, when it hit me: almost all of my “resolves” for 2014 are really about decreasing my productivity.
I want to:
-cook most of my meals at home
-plant a bigger veggie garden
-fret less about money
-read more books
-take long walks
-write for pleasure
-own less stuff
-do yoga, daily
-go camping, monthly
-be a better friend/neighbor/colleague/family member
-live closer to where I work
Recently I was speaking with a scholar-friend about a new “Pacific Worlds” project that I’m working on. As I outlined where I was in my research process, he remarked that one of the most time-consuming elements of starting a new project, is assembling a list of seminal works in the field, and ensuring that you’ve read each of them and understand how they’re in conversation with each other.
In that vein, I thought about how much time I spend “mining” the bibliographies of other scholars to gather the relevant readings for my own work. Doing this is time-consuming, particularly if one is hand-entering the relevant data into a spreadsheet or bibliography database. Using a resource like zotero allows us to bypass some of that searching/data-entry process, but that only really works if other scholars in your field are also on zotero and are sharing their research folders (i.e. it’s pretty unlikely if you’re in any field outside of the digital humanities).
So, I decided that I would jump in and share the resources that I’ve compiled thus far with this new project. To do so, I added the “ZotPress” plugin for WordPress to this site. As I type this, my zotero library is being imported into my WordPress install:
It’s taking some time–my zotero library is pretty sizable.
And now, just a few minutes later, I have a webpage of my growing bibliography for this new project. ZotPress allows you to insert a shortcode to display the citation data from a zotero folder or from any number of other parameters (author, category, etc). And you can also choose from a variety of citation styles to display your data.
“Students in history [must] learn techniques of project management” because of the growing need for collaboration on “Big History” projects, says James Herbert in the most recent issue of Perspectives (the magazine of the American Historical Society), in an article titled “Professions and Publics.” Herbert is paraphrasing the words of author James Cortada, who writes about the ways that historian need to change their research practices in his recent book History Hunting: A Guide for Fellow Adventurers.
It would be nice to see those skills incorporated into graduate school, but I can hardly imagine such a sea-change occurring anywhere but at the most innovative of institutions, where staff support, in the form of technologists and project managers, is available to graduate students. Off the top of my head, I can only think of two (well-heeled) programs that might have such resources allocated to their graduate students. Few (too few) even have technical support for faculty, much less their students.
I haven’t yet read Cortada’s book, so perhaps it’s premature for me to offer my concerns about the practicality of his suggestions. However, I’m looking forward to reading it to see what concrete ideas he offers about how this change in curriculum might fit into the training of students at non-elite universities.