Quick Layout Testing and Calling It a Day

I’ve been working on a project recently at Performant Software, let us call it Project B, that I’m very excited about but can’t reveal because it hasn’t been publicly launched yet. For this project, the client wants to send smart-phone users into libraries in order to crowd-source pictures of old books (that’s the broad outline—the specifics are a little more interesting). We have customized an installation of WordPress with a responsive theme and an upload form for images and book metadata.

In order to keep the budget for Project B lightweight, we did not subcontract any design work, but we have been tweaking the WordPress theme in accordance with the client’s wishes.

My last substantial task of today was to confirm the latest design updates and mark them “accepted” in Pivotal Tracker.

Now I’m off early for a trip to a concert at the Kennedy Center!


As part of my work as a project manager at Performant Software, I supervise work by our production assistant, Susan. In the past hour or so, I’ve had the following interactions with Susan:

  • She consulted me on an odd-looking test result from our iOS project, and I decided that it merited filing a bug report for the developer to investigate.
  • She advised me that after a lot of trial and error, she’d finally gotten a certain piece of software up and running on one of our office computers. The software in question is an old Windows program, delivered on DVD, that we’ve been tasked with reinventing as an interactive, web-based program.
  • I had asked her to look into pa11y, an automated test for web page accessibility that I had read about on ProfHacker. Susan let me know that she had run into some errors when trying to install pa11y on her computer and asked if I knew anything about the errors. I didn’t, so Susan said she would keep working on trying to resolve them herself.

(Soundtrack as I type this post: Iestyn Davies’ brand new CD of John Dowland songs, called The Art of Melancholy. It was released today and I swooped home at lunch to pick up my Amazon order so I can take it to a concert and signing tonight!)

Preparing Testing Notes

One of the principles of agile software development, which we practice in a “lean” form here at Performant Software, is that the software development plan should be open to change in response to feedback from the client and test users.

I have a similar attitude towards my role in project management. We have a general process for managing all of our software development projects, but I adjust my day-to-day practices to meet the needs of the project, the client, and the developer(s).

Currently, we are getting very close to wrapping up development on an iOS app. The client is a local artist, and the app will be a variation on one of his art projects. In this case, the client has raised some questions about our testing process and the readiness of the software for release, so I have asked our in-house software tester, Susan, to write up her testing results in more detail than usual. I’ve been editing her testing notes to prepare them for presentation to the client at a meeting tomorrow.

For most projects, we open Pivotal Tracker to the client and let them read our brief testing notes there. We also try to give the client access to a staging site or testing release of mobile software as early and often as possible so that they can do as much of their own testing as they wish.

In the case of this particular project, the client needs something more in order to be satisfied with the results of testing, so it is my job to provide what the client needs.

(Soundtrack for this part of the day: still listening to Rodelinda. Just got through Iestyn Davies’ rendition of “Vivi, tiranno.” Pretty satisfying!)

Sending out a Statement of Work

One of my major job functions as a project manager at Performant Software is to write up statements of work (SOWs).

When a prospective client approaches us with an idea for a digital project that they want to develop, we talk with the client to understand what they are trying to accomplish and what the scope of their resources is. With academic clients, I try to understand the intellectual underpinnings of the project: what is the client’s research or teaching agenda? Does the project come from a particular theoretical approach to the subject matter? How does it fit into the environment of other digital humanities projects?

From these initial conversations, we develop an SOW. I coordinate the process, working with our in-house developers to describe and estimate the needed software. I also get quotes for design work and hosting from outside firms, when relevant. I write up all the expected costs of the project along with a description of the project’s purpose as we understand it and the broad outlines of the software solution we expect to develop. Then I send the SOW to the client, who can use the document in applying for project funds from their institution or from an agency such as the NEH Office of Digital Humanities or the Mellon Foundation.

This morning I sent a finished SOW to a prospective client whose project I really hope to collaborate on. I can’t tell you too much about the project since it is only prospective at this point, but it would involve creating an online electronic archive for a collection of materials relating to a specific topic in African American history. I will be very excited to add this project to our portfolio, if the funding works out and the project goes forward!

Since the prospective client in this case has never done a digital humanities project before, I tried to put a little extra care into explaining what technologies we propose using for the project and why we picked those technologies. My essential job function is to form a bridge between the software developers and the clients, helping the developers understand our academic clients’ objectives and helping the clients understand the technologies we’re working with.

(Soundtrack for this part of the day: Handel’s Rodelinda, performed in English recently at the English National Opera, with Rebecca Evans, Iestyn Davies, Susan Bickley, and John Mark Ainsley.)

Starting the Day

Welcome to my Day of DH! I am a project manager at Performant Software Solutions, where I specialize in collaborating with academic clients on digital humanities projects, although I am also involved with some of the company’s non-DH projects. Although I have an academic background, I will be blogging today about working on DH from the software production side.

I started today, like every day, by reviewing all of the new emails that have landed in my inbox overnight. I was especially pleased by a message from a QA and support manager at Pivotal Labs. Here at Performant, we rely on their Pivotal Tracker online project management software to organize, delegate, and track our software development work. The developers at Pivotal Labs have recently made a number of changes to Pivotal Tracker, and I sent in a comment saying that one of the new features had made my workflow more difficult to manage. Pivotal Labs responded by giving users the option to go back to the old feature. I really like the fact that they not only responded to user feedback (the mark of a good developer!) but also sent me a notification letting me know exactly how to get the old feature back. Thanks, Pivotal!

(Soundtrack for starting the day: Handel’s Birthday Ode for Queen Anne, sung by Andreas Scholl, Andreas Wolf, and Héléne Guilmette. I like to start the day with a little musical optimism.)

Day of DH 2014

Skip to toolbar