Building Bridges: A Study of Coordination in Projects
On August 13, I successfully defended my dissertation. Today, I submitted my final, approved version to University of Michigan's institutional repository. That version won't be available until after I receive my degree in December, but you're welcome to read a nearly identical version of my complete dissertation.
Dissertation Abstract
In our efforts to understand how collaborative work can be accomplished, we often turn to discussions of “coordination” for help. However, the concept of coordination is inadequate for explaining the many interdependent processes at work within successful collaborations. In this dissertation, I examined a collaborative construction project – the Woods Avenue Bridge (WAB) Project – with many coordination demands. I used data from this project to develop the concept of adaptive capacity – the set of capabilities a team develops that enable them to adjust to internal and external stresses.
Through analyzing meeting minutes, interview transcripts, and documents the project team developed, I was able to identify behaviors and approaches the team took that may have enabled them to better respond to changes in their environment. I use a specific example of a time when the team successfully redesigned the structure they were building in the field to illustrate the kind of coordination work adaptive capacity enables.
From data about the WAB Project, I identified components of adaptive capacity including perspective taking, multimembership, affect, and social capital. Understanding these components and the adaptive capacity they can develop helps us understand what about a team enables them to accomplish coordination work. Without adaptive capacity, we lack an integrated explanation of the ways in which different components interact and how those components address coordination.
This dissertation contributes to our understanding of how collaborative teams accomplish coordination by refining the concept of adaptive capacity and integrating earlier literatures on coordination, collaboration, and adaptation. The concept of adaptive capacity helps us understand the resources collaborative teams develop that make it possible for them to find flexible and creative solutions to their coordination problems.
Current Research: Joining Virtual Organizations
People keep asking me what I'm working on now that I've defended my dissertation and moved to Arizona State. The answer is, "research!" More specifically, I'm working on a research project to understand and improve the experience of joining a virtual organization. My colleagues, Erik Johnston and Stephanie Teasley, and I are studying post doctoral researchers who joined (or are joining) virtual science research organizations. I've made a diagram of our research process to make this more clear (click the image for a larger version):
The red parts represent the inductive, qualitative portion of our study. I am primarily responsible for those stages of the project. I am currently collecting data, and that's why that piece looks different. Erik is primarily responsible for the deductive portions, those in blue. This diagram was inspired by process diagrams of grounded theory and deduction from
Gasson, S. (2003) Rigor in Grounded Theory Research: An Interpretive Perspective on Generating Theory from Qualitative Research. In Whitman, M.E. and Woszczynski, A.B., eds. The handbook of information systems research. Hershey, PA: Idea Group.
Gill, J. and Johnson, P. (1997) Research Methods for Managers, 2nd Ed., London: Paul Chapman Publishing.
The Wrongheadedness of Best Practice Thinking
I’ve come across a gem of a book introduction, and I’m writing to recommend that you read it. Yes, all of you. The introduction is from the book Strategic Procurement in Construction
Cox and Townsend argue in their introduction, and throughout the book, that best practice thinking is wrong-headed and leaves us playing catch up. One of my favorite bits of the introduction reads:
They will be searching for the ‘Holy Grail’ of best practice. By this one means practitioners are looking for the answer that provides the solution to all of the problems which they face managerially. Unfortunately, this desire to discover the single solution (best practice), that will allow the practitioner to avoid the need for thought and risk taking, is an illusion.
They go on to discuss concepts such as appropriateness and leverage and recognize that many practitioners would call their discussions “common sense.” Their response?
Some of the practitioners who read these pages may accept what has been said, and argue that this is just common sense (which it is), and that they already know this. If that is the case then this book may have little to teach them, however, because experience leads the authors to conclude that such a form of sense (in a business context) does not appear to be all that common.
I wish I’d written something like that in the paper Andy and I submitted recently that was rejected for having results that were not surprising enough. The results we found in our onboarding study were surprising because we found them and not necessarily in their content. For instance, it’s surprising that teams still behave as though new employees will be immediately productive even though the sense that onboarding takes time is apparently common. Much like Cox and Townsend find that strategic procurement is not all that common, neither are teams who smoothly onboard their new members.
My questions as I continue to read Cox and Townsend’s book are really about how one encourages strategic, reflective thinking over best practice thinking and how one should present research results that show just how uncommon common sense can be. See, one can learn things by studying construction projects. This message brought to you by my dissertation, a work in progress.
A Productive Summer
Andrew Begel and I had a very productive summer. We conducted 95 interviews with 26 people, and spent 7 days onsite observing new remote employees. We'll be presenting a poster titled, "How will you see my greatness if you can't see me?" at CSCW in November. The poster session is Monday night, Nov. 11. Come by to hear more about our study, especially our findings about how excellent work is and is not observable from a distance. Stay tuned; we're submitting longer papers to two other conferences, and I'll post here when they get accepted.
Related links:
Human Interactions in Programming Group at Microsoft Research
ACM's Computer Supported Cooperative Work Conference (CSCW08)
A new vocabulary
I'm lucky to be the kind of researcher I am. I get to observe and interview people who do really cool work and to learn about what they do. A couple years ago I learned how vaccines for Black Plague get made. My dissertation lets me learn about how bridges (real ones, not just metaphorical ones) get built. Now, at Microsoft, I learn how software is built. Over the last couple of weeks I've been interviewing managers of developers and testers at Microsoft in an effort to recruit them for my study on remote onboarding and to learn about what they do.
Years ago, before I came back to grad school, I had the illustrious title "Developer" at a web start up in Chicago with about 100 employees. A "software team" there was a project manager, a developer, an architect, and a designer. We built websites. My job was to write ASP code that made the designers and project managers happy. Towards the end of my career, I wrote ASP.NET code. Somewhat more complicated, still produced a website. "Developer" at Microsoft means something a bit different. Developers at Microsoft build stuff that matters - Windows, for example. They do it in teams using tools such as Source Depot, Razzle, test harnesses, RSOPs, WTT, and TFS. They meet in scrums, war rooms, Live Meetings, Office Communicator, one-on-ones, and code reviews. Those 12 phrases and acronyms are new to me. Not one of them had I ever heard before. I now know what 5 of them mean. I'll leave you to guess which 5 I know.
Learning the vocabulary of my subjects is just one part of my research, but it's been a while since I had so much specialized vocabulary to learn. The phrases and acronyms the engineers I study use seem a bit more intuitive to me, things like "pancake test" and "aggregate" are nearly self-explanatory. Granted, "code review" means about what you think it does but "scrum"? No, developers are not playing rugby.
Being a new employee while studying new employees is so meta I can hardly handle it. Perhaps next week when I meet my first new employee subjects I'll start to feel like I have a better handle on the situation. For now, while I'm meeting with managers, I'll just keep typing as fast as I can and hope that I'll know when to ask for help.
Faculty, staff, PhD students band together for ASB
SI has a rockin' alternative spring break program for MSI students. One way money gets raised for ASB is through an all-school Penny War in early February. This year, the Faculty, Staff, and Doctoral Students team came on strong in the last two days to completely dominate the Penny War. We were a dismal last place last year. Someone from the student affairs staff sends out nightly updates about the Penny War, and we came on strong in the final days after some goading from the Dean and strategy help from Jeff Mackie-Mason. The Penny War doesn't recognize individual performance, but all of SI can be proud of ourselves for raising $2086.91 this year. Nicely done. I hope ASB is as rewarding for this year's group as it has been in the past.
Explaining myself to technology product groups
I have a meeting tomorrow with a leader of a product group at a Silicon Valley-based household name. On the itinerary, I'm described as "a PhD student who has worked on use of social media and etc. by science and engineering research groups". I've been asked to come up with a 3-5 minute introduction for myself. Here's my rough draft:
Your itinerary shows that I’ve worked on social media use by science and engineering communities. Another way to think about what I do is to call it social computing for existing (or emerging) social systems. My work is with distributed teams, and it’s different from much of the existing ecommunity work because the teams I study know each other. They may not be close socially or geographically, but they are familiar with each other and have almost always met face-to-face. They’re working together toward some goal that requires them to collaborate (e.g. getting a new building technology to market) or benefits greatly from collaboration (e.g. getting through grad school). They span a variety of distributions – whether their offices are states or continents apart, whether their disciplines seem distant, and how they span the spectrum from novice to expert.
Two of the projects I work with now that explore the use of social computing by existing communities are the CI TEAM grant and KNOW SI. In the CI TEAM grant we explore how engineers developing and testing a new building material work together across institutional and national boundaries to establish standards for testing the material and for training new users of the material. The CI TEAM group uses a content management system with features somewhat like Yahoo! Groups to share their data and discuss it. CI TEAM builds on earlier large-scale scientific collaborations that used the same tools but had very different motivations and goals for collaboration. What I’ve found most interesting in these scientific research collaboration projects is how unlikely users are to adopt a technology specifically for their projects. Users love email and Excel but ignore wikis, archived email lists, and file repositories.
KNOW SI is a PhD student-led project with many goals. Mine is to use KNOW SI as a way to understand how people in organizations, such as schools, use available technologies to share information with one another. In KNOW SI, I helped set up an iterative series of wikis for use by the community, and we’re analyzing that use and preparing the next generation wiki. What’s surprised me here is how willing various groups are to use the same underlying technology. For example, doctoral students are all over the wiki. We’re our own audience though. The Research and Career Services offices have different audiences – master’s students and the public for two – but are exploring the same technology.
Together these projects provide a variety of settings for me to explore information and technology use in different kinds of collaborations.