Sebastian Ferrari - Portfolio

What is Contextual Inquiry?

In the School of Information one of our required classes puts us to work with an external client to help with a product or a workflow problem using a method of ethnographic research called Contextual Inquiry, developed by Hugh Beyer and Karen Holtzblatt. Put simply, contextual inquiry means going into the workplace and observing the user in their "native habitat" as they work with a product and collaborate with coworkers, and conducting interviews in which the interviewer is more like an apprentice and the interviewee is the master. Students in the class work in a group over the course of the semester with the client and produce a final report with findings and recommendations.

The Client

My group was assigned to the Office of Marketing and Communication at the School of Information. The department was struggling with a transition that began roughly two years before when it made the leap from being a service unit within the School of Information to being a full-fledged strategic unit. Around the same time as that transition, a new Director was hired, but there were no other real changes made in the department: full-time staffing levels remained the same (two employees) though many part-time temps were brought in; the organizational structure of the department remained unchanged; and previous workflows remained largely intact.

Our group was brought in by the Director at a point when the department had reached a breaking point. The School of Information had recently added an undergraduate program, had the largest entering cohort of Master of Science in Information students ever, and the SI website (for which this department bears significant responsibility) had undergone a significant update. As a result staff members were falling behind and not meeting deadlines; members of other departments at the School of Information were worried about the status of joint projects; and numerous communication breakdowns were taking place, both internally and externally. Our project scope was to assess

the department's internal project management practices;
the department's communication with other departments and external units, including their updates on the status of projects;
how best to generate metrics for individual projects so as to better measure efficiency and workload on staff members.

Data Collection and Analysis

We conducted seven interviews with full-time and part-time staff members of the department and with staff members of other departments within the School of Information which have frequent interactions with our client's department. All the interviews were conducted in the workspace of the interviewee so that we could also observe their work environment and their daily work routines. The group members shared equally in doing the interviews and all of the work during the semester, though we also had individualized roles (I served as the client contact for the group). We coded our notes from the interviews and with this coded data we constructed several data models for analyzing the results. We made individual cultural models for each interviewee and from these models we generated a consolidated cultural model of the department. The consolidated cultural model (shown below) shows what and who might be influencing the department and its various members.

Next we made a flow model depicting how projects move through the department and identifying several places where projects do not move very efficiently.

The last data model we employed was the affinity wall, which was built out of our coded interview notes and revealed the big picture themes we would use in the final presentation of our findings and recommendations. Here's a picture to give you an idea of what a segment of our completed affinity wall looked like like.

Findings and Recommendations

While some of the themes that emerged through this process were apparent from the beginning, others weren't. For instance, we came to see how much the department suffered from being a high inertia system, which is a rather technical way of saying that a lot of legacy issues were weighing it down. These legacy issues originated from the department's days as a services unit when its workload was lighter and when the department did not have a strategic role at the School of Information. In those days the department was rather tight-knit and there was not much of a compelling reason for establishing clear hierarchies and specific workflows for projects. We also learned that the on-boarding of so many temps over the past two years had introduced confusion with regards to job roles and reporting hierarchy.

Our recommendations were split into short-term and long-term, and they were designed to be practical and reflective of the unique situation and culture of the department. The recommendations included

the requirements needed for a successful project management software solution for the department given the varying technical expertise of staff members and their past experiences with project management software;
the establishment of protocols for communication within the department: among other suggestions, we encouraged the use of face-to-face interaction over Google Hangouts given that the department had recently been split up and divided between two buildings on campus;
what would be needed to keep other departments informed of progress on projects until a project management software platform could be decided upon;
in the long-term we suggested that the hiring of a full-time project manager and client liaison would be necessary and we included what we thought would be the necessary qualities for a successful hire given the needs and culture of the department.

I hope to update this page in a few months with information about how the department incorporated our feedback and what the results were.

Update (December 2014): Below is feedback we got from our client about the impact of our report, approximately one year after it was turned in.

The report identified the following solutions:

Adopt project management software that: addresses individual work requirements and styles (primarily those of non-developers), creates metrics for department production, prioritizes projects on a timeline, and comes with adequate training (including scheduled time for such training), departmental buy-in, and top-down enforced use.

If future budgets allow for it, a full-time project manager who also serves as client liaison should be hired

Establish department-wide protocols for communication, and facilitate as much face-to-face interaction as possible (including via Google Hangouts); in the long term, having the department reunited and close to relevant units of SI would be ideal.

Employ an externally-facing spreadsheet, website, or other application that keeps clients updated and which is managed by one person in the department based on information generated by internal project management software

At the time of the evaluation, we had already adopted project management software, but the group had noted that our attempts had failed and the report included detailed steps to make our next attempt more effective. We followed those steps by rolling out TeamworkPM, and met their fourth recommendation in the process. The group deserves some credit for this, noting that we achieved school-wide buy-in.

[We] had already planned to hire a project manager prior to the 501 evaluation; we are seeing good returns from this decision on a consistent basis. Not sure the report had any effect on this outcome, though.

The third recommendation (excluding the move back to NQ), honestly, is one that they detailed and one that we continue not to hit. In the details, they insist on a method for holding external clients to account for poor planning and flatly refuse projects that would put us over capacity. Additionally, they recommend regular meetings with agendas, rather than regular meetings with a fixed format, as well as breakout meetings for teams. We continue to work toward this end goal and have made significant improvement since the report was issued, but our implementation on this one is inconsistent at times.

TL;DR They did a good job outlining how to make the software a success, and their recommendations for improving group dynamics are valuable but challenging.

The Value of Contextual Inquiry

What I most enjoyed about contextual inquiry was its affinity to a method I employed in many of my literature classes, that of close reading. Close reading forces you to keep close to the grain of the text, which prevents students from veering too far off in their interpretations since everything must be securely grounded in the text.¹ Similarly, contextual inquiry and the data analysis methods we employed (affinity walls, cultural models, flow models, etc.) reinforce the need to stay close to the data so that your findings can be accurate and your recommendations can always be backed up by the data.

I also liked that contextual inquiry requires you to be humble, to enter into the user's workspace and to be their apprentice even if for just an hour. If it's done right, that's where assumptions die and revelations are born. I frequently make the point that as a teacher (as someone who is supposed to know) I actually am continually learning from my students. It doesn't matter how many times I've read a text, invariably someone in the room will bring a new perspective that opens up the text in an enlightening and fresh way. So it is with users: they are continually teaching us something new. Contextual inquiry recognizes this fact and is predicated on the idea that you have to listen to the user, and then secondly, listen to the data.

The Team

And finally here's a picture of the team in front of our finalized affinity wall! My fellow group members on the project were (from left to right) Colin Drayton, Allyson Mackay, and Rushika Deshpande, me, and Michelle Fiesta.