Tag Archives: TomScheinfeldt

css.php

Consensus isn’t what collaboration is about

Consensus isn’t what collaboration is about. This take-home-point by Tom Scheinfeld stuck with me, and I found myself saying it out loud to a group of people at work. This is an important point that bogged our web project down in the planning stages of post.at.moma.org. The struggle of early stages–lack of consensus and leadership on what the website should be, it’s goals, its tone, it’s audience it’s measure of success, etc.–still is visible to a visitor who spends a little bit of time on it. The project lacked a visionary who knew and believed what the project should be.

Instead of gaining consensus of the group, Scheinfeld stated that if a positive outcome is accomplished, led by a few members of the group, that is what the collective will remember–their achievement as a group. But for this achievement to be accomplished, someone must asses the best possible outcome and make a decision. My question at that moment was, how do you, as a leader decide on something? How can you be confident that it will work? Maybe you don’t until you take the chance? Is the definition of a leader, someone who confidently takes chance on something?

Another probably obvious point that didn’t always seem clear to me, is that the measure of success should be based on whether people use it. Despite the institutional agenda, and ideologies and high standards that motivate projects, if there isn’t a practical utility value that serves people, it’s not successful. The number of people that the project considers a success, though, requires some thought. As project that caters to a specialized audience (particular topic in art history), it needs to determine what that limited number of audience is, that it should strive toward. There is pressure to serve a general audience, and have many visits per day, but the content of the site cannot appeal to a general audience. A specialized and devoted follower, who values the content of the site is needed, but the number of that audience is yet to be determined.

There were many golden advise that Scheinfeld left during his talk and discussion. Here are a few more that I will keep with me in the future wherever I end up working as a professional project manager:

  • value constraints (think about the 7-day turn around)
  • make time for social interaction (meta cognition)
  • assessing people’s skills. Determining the types of skills the group has, and the type of skills that need to be acquired.
  • think of set of critical questions; always ask what it’s missing, and think of the overall picture
  • list the criteria for the measure of success
  • divide a group to execute different things
  • watch out for unthoughtful moves. There is risk of losing members’ urgency, respect, trust, etc.
  • create process documentation. This could be part of the out-reach (tweeting out the progress or reporting on a blog)

An incredibly valuable session, the text by Sharon M. Leon also provided practical tips on project management. I would be curious to hear about the workshop that evening, which I couldn’t make. Classmates: let me know if any of you made it to the workshop and please share with me your take-home-points!!

 

One Prof One Book?

I enjoyed Tom Schienfeldt’s presentation on his One Week One Tool initiative. One thing in particular has stuck with me. After his talk, the question of Project Management as applied to academia came up. Mr. Schienfeldt made the point that corralling humanists into working together is difficult. It’s really a shame this is true.

People can do so much more when they work in a team possessed of complementary skills, and this applies to academic pursuits in the Humanities as well as any others. It’s often said at this point that successful collaboration happens all the time in the sciences. What is so different about the humanistic fields that makes collaboration so hard?

Many say it is because a monograph, apparently the great proof of academic accomplishment, succeeds best as a solo undertaking. It’s the concentrated expression of a single person’s study and thought. Why is this valued? Partially because the subjects of the Humanities are thought of as subjective, or at least contingent. The monograph form also evolved partially as a response to the need to recognize academic accomplishments, designed to make it possible to give credit to one person.

But, the monograph isn’t the inherent form of humanistic expression. Group projects, while they look different from monographs, can still provide unique contributions to knowledge. They might take the form of an archive, or a ‘social edition’, or any number of arrangements not invented yet. And, if expectations change in order to recognize group work, some academics will consider it in their best interests to work together.

Even the monograph form doesn’t exclude group work. It is possible to assign appropriate credit for each author’s contribution to a multi-author monograph, eg, by assigning authors to write individual chapters. Imagine, however, a book written truly collaboratively, with each author’s text intermingling with the others’. Authors could use a version control system like Git, letting them work simultaneously on the same text without interfering with each other’s progress–and allowing judges to assign credit, using Git’s Diff function to see who wrote what.

By the way, I’ve employed just such a collaborative model using Git & Github (see the source code here), working with Alevtina Verbovetskaya, Robin Davis, and Junior Tidal, for a presentation we are making on the topic Life with Pi: Microcomputing in Academia to the CUNY IT Conference this next Friday, December 6th. Come on by if you’re interested!

Lessons

Great posts all about Tom’s presentation on Monday. What I think One Week/One Tool demonstrates is the positive benefit of using digital technologies to help us break free of the intellectual, organizational and psychological constraints posed by traditional academic thinking and work processes in order to imagine new ways to achieve academic/intellectual ends, whatever those may be. It’s less about figuring out if One Week/One Tool is the right approach for us to use in the Digital Praxis class moving forward and more about embracing that kind of unconventional thinking that Tom exemplifies about our conceptualization and production processes in the academy. How we get to that point (i.e. the exact procedures we decide to use) is less significant than our willingness to embrace new possibilities and new methodologies.

Catching Lightning in a Bottle

It’s interesting to reflect on the discussion channels pouring out of Tom Scheinfeldt’s presentation about One Week | One Tool. It seems we’re contending with how to infuse the energy and spontaneity characterized by some of the One Week | One Tool ethos into our yet to be, semester long projects next Spring. The attraction I, and certainly others see in a short term, intensive program like One Week | One Tool is exactly the phenomenon Tom Scheinfeldt remarked upon- this freedom within constraints, this ability for the clear (just the right kind of spooked) mind to shepherd in powerful concentration and creativity.

We make very fuzzy visualizations about what next semester’s project might really look like or turn into- and we’ve had plenty of time to let our imaginations run rampant without the ability to put any of this energy into doing the project itself. And I think this speaks directly to another of Scheinfeldt’s points- stress creeps in when we don’t know what’s expected of us. We haven’t gotten there yet, so we certainly aren’t able to grasp the expectations.

One Week | One Tool aims to catch lightning in a bottle by giving willing attendees the opportunity to collaborate and produce results under extreme pressure. How can we leverage that ‘camp’ like energy and combine it with more traditional project timelines for the better of our projects?

Perhaps we can start with an approach similar to how Scheinfeldt described this summer’s One Week | One Tool participants’ working process. First, a rapid brainstorming session, followed by a few rounds of viability and assessment discussions. Projects would be conceived in a short amount of time, and there would be an emphasis on developing and testing the tool quickly. I think it’s crucial to be really strategic and cognizant, yet make haste on the design and development side of things as often the concept and reality can get conflated and cause distortion- really putting a wrench in the project’s momentum. We could then take the results to our constituents: the end users and ‘funders.’ This would give us more of an opportunity to interface with crucial stakeholders beyond project participants, and hopefully enable reworking phase(s) in order to work out some kinks.

 

“Twitter and Blogs are first drafts of scholarship…”

Borrowing that line from samplereality’s Tweet, the writer Mark Sample was correcting a statement after realizing the project George Mason University’s Center for History and New Media and Tom Scheinfeldt was launching, Anthologize, planned to give ‘better binding’ to such scholarly works. As we have learned however, the One Week | One Tool project has done more than just provide an application for “publicizing” blogs and mapping texts with possibly related and funky imagery. Analyzing collaboration within a new realm of scholarship is the real gift of the seven day, twelve person project.

However, as was said by Ms. Stevens earlier, the One Week… project was an experiment in highly irregular circumstances. Time is an issue which obviously will present itself in any situation. Gioia is correct though: The focus should not be on “crash programs” strategy and management. Any group forming a consensus will run into problems of disagreement and the question of internal leadership may or may not also rise. But with regards to DH, how could people facing ordinary constraints (time, money, jobs, families, multiple competing projects, laundry etc.), complete projects with greater efficiency.

Unfortunately, I am unsure what more can really be added from the previous post.

Collaboration and creative constraints

The One Week | One Tool project shows that time and resource constraints really can be made to work in a project’s favor. Twelve strangers who committed to seven days of all hack, no yack, and very little sleep made some great tools (Serendip-o-matic, Anthologize). Creating severe constraints can foster both collaboration and creativity.  Tom Scheinfeldt pointed out three key lessons for successful collaborations: 1) embrace serendipity 2) let go and 3) collaboration is shared doing.

DH barn raising projects are inspiring, but they are artificial laboratories of collaboration. How many of the lessons will be useful outside of an intense, boot camp style workshop? I agree that collaboration is shared doing, but I started to wonder when Scheinfeldt pointed out that time constraints can mean sacrificing shared decision making.  My workplace culture focuses on consensus building, so I found it both slightly shocking and secretly delightful (those staff meetings are long!) when Scheinfeldt said “Moving on will mend hurt feelings more than talking about it.”

What about collaboration for the rest of us? Very few people have the luxury of attending a week long workshop. The real world has plenty of constraints (time, money, jobs, families, multiple competing projects, laundry etc.). What are best ways to use these constraints to promote collaboration and creativity? Maybe it’s less about crash programs and more about intelligent adaptation to existing conditions? Starting a business (designing the right product for the right market) or gardening (choosing the best plant to thrive in a particular location) could be useful examples for thinking about the best ways to use what we have to build something together.