Updating Documentation
Now that there are a few new members of the lab, it’s time to pay attention once more to making explicit some of our expectations and shared experiences. It’s interesting to watch, and to test, how stories or catch phrases easily become part of a local culture… only to be met by blank stares when a new person experiences it.
“What’s the best dissertation?” “The one *you* can do in a reasonable amount of time.”
“Is that a title of a song on the album?”
” Delta Pain” (which is a title of a song on the album)
All of these represent elements of tacit knowledge, in that they are shared and understood by people who were in the lab when the event occurred, or maybe in an individual meeting with me, and have learned to experience and internalize the informal lessons of the lab in a particular way. That’s great for an individual mentoring interaction, but not really good for organizing the productivity of getting a population of students to finish high quality thesis and dissertation documents. Thus, we have to do some of these things with more explicit intent, and a more focused and determined documentation of elements of the lab’s culture.
Since the beginning of the Spring 2013 semester, we’ve been working on this in the creation and updating of four distinct documents: A Master’s Thesis outline; a Dissertation prelim outline (oh, even that’s tacit, or at least implicit: the proposal document written in order to describe one’s dissertation so that one can be advanced to candidacy); a Doctoral Dissertation outline… and most recently, a semester-by-semester timeline for progress towards degree completion. These seem to be very helpful for students, and help to summarize and integrate and transmit my experience in a fairly efficient way. And why not? I’ve supervised over 30 MS theses and 12 PhD dissertations, and sat on committees for another 25 or more graduate documents. Most students, on the other hand, only do this once. (I did have one of my students complete a second MS with me after finishing a first one elsewhere; no GROUPERs have ever tried to do multiple PhD dissertations.) Rather than make everything trial and error, or suggest that there is no pattern that leads to increased probability of success, some people (among those are many engineers) would like to have a sense of the path, the rule, the “game plan” of how this graduate experience is supposed to play out.
Does this mean that there is a fixed and rigid procedure that everyone must follow? Of course not, for several reasons. One is that GROUPERs are different people, with different skills. They don’t want to work in the same stream, or using the same data collection or analysis tools, or ask the same sorts of questions. Fortunately, I’ve worked in a bunch of areas, so my tolerance for procedure variability is fairly high–I can advise a variety of dissertations, because I have done a variety of projects in different areas and methodologies. (Some people may think of this concept as akin to Ashby’s discussion of “Requisite Variety”; no strict quantification here is implied.) So, the level of consistency is not at the detailed level of “you must design a three-level, two-dimensional Analysis of Variance studying the influence of…” Everyone is expected to be able to answer, “Why would anyone want to read this thesis / dissertation?” or “Why do we care about the question, or the work you did to answer it?”
It may also be relevant that one of the recent dissertations now making its way to conclusion is specifically addressing the question of procedure reliability and complexity. A very often-repeated task, with few new or challenging elements, can have a standard procedure that is rarely, if ever, inappropriate for completing the task as designed. If you’re developing a brand new task that has never been tried before, it’s highly unlikely that you can write a perfect procedure on exactly how to do it. Most procedures are somewhere in between, even if we assume the procedure is always right. At what level should we expect a new procedure to capture all of the experience that we gain in the development of a new system?
As time goes on, all of these documents will need to be updated–not necessarily because we were wrong, but because our knowledge evolves. (OK, I was explicitly wrong on this item. I forgot to include a version of the well-known advice: “Tell them what you’re going to tell them. Then tell them. Then tell them what you told them.” In other words, the last section of the introduction chapter should include an outline of the organization of the remainder of the thesis / dissertation.) Even the working of the updating process is a helpful way of sharing the experiences and telling the stories of the lab. And when we’re done, current and future generations of GROUPERs can know that I won’t get upset if they haven’t taken 15 credits or completed their plan of study or research proposal by the end of their first semester in the program. Really.
I know, you’re wanting the links to these documents. They’re still under construction. Check back when they’re done and posted.
grouperlab 
June 28, 2013
Communication and Documentation (longer, connection-enhanced version)
Communication and Documentation
[I am feeling a bit like Chuck Lorre, the producer for several extremely popular television series, including the The Big Bang Theory (TBBT). Chuck has “vanity cards” which appear very briefly at the end of each episode of the shows. These vanity cards express Chuck’s perspectives, insights, and fevered rants on a variety of topics, and basically act like a blog. Since I record TBBT quite extensively (any similarities I have to Sheldon Cooper will be, and have been, hotly contested), I have gotten good at pausing the recording to read the card. Every once in a while, the card makes some reference to censoring, but with a website address to indicate where you can read the uncensored version of the card. When I first created the “Communication and Documentation” entry for the Indiana Space Grant Consortium Director’s Blog / Notes, it was pointed out that it was long and tangential and wouldn’t appeal to some of the readers. Well, in Chuck Lorre fashion, I edited the blog entry for that audience, but here’s the full version. Why? It’s GROUPER—so, it’s because I can. And those of you in GROUPER will recognize Karim and know why Shannon and Weaver are important. So there. –BSC]
“Document your code!”
This is a lesson I remember from my first computer programming course as a college frosh, now more than 30 years ago. The language was FORTRAN, and the computer was a PDP 11/44[*] but the lessons were the same. If you didn’t provide enough comments in your code for the instructor to understand what your logic was intended to accomplish, or what the variables meant, or what that subroutine was for, you got points off. The essential message was not subtle: no matter how good a job you think you did, you haven’t done the whole job unless you’ve effectively documented it. Over the past few weeks, I’ve had substantial reminders of the importance of those lessons of communication and documentation.
Since the Affiliates’ Meeting in April, the INSGC staff have been trying to upgrade our processes and activities, and bringing onboard a new set of student interns for the summer. Part of this comes from our Affiliates’ survey of communications with the Central Office. Although the overall responses were excellent (from the perspective of demonstrating to NASA that we take our performance seriously and assess it regularly), there were some areas of concern (from the perspective of continuous improvement and achieving a model of excellence). It’s clear that we could use our website to better advantage, and thus that is a priority for us this summer. Angie has reported a much more timely and useful set of responses to our requests for reporting, due in part to our more clear presentations of what, when, and why we need those reports to meet our NASA grant reporting and documentation obligations. Wow… we can get that much more just by being more explicit about what we’re looking for, and how we need to use it?
Effective communication is a tricky thing. Some people like their documentation “spiced up” a little bit; others just want the immediate facts, in order, with an agenda of what will be covered and how many minutes are associated to each fact. I just had two conversations this weekend highlighting these challenges. On Friday, I had dinner with one of my former students, who recently started a new job at a major hospital as a quality engineering and improvement manager. He noted that some of the physicians and others at the hospital were frustrated with some of his meetings, because they couldn’t see how, or whether, there was a point to the meeting and what they were supposed to recognize and respond to that point. (Interesting: that was, almost verbatim, one of the comments from our Affiliates’ survey.) He said that those people would have found our research lab meetings intolerable, but he then took the feedback as an indication to simply write down what he already had in his head and give it a more formal structure as a meeting agenda. I have had to learn the same lesson in our INSGC Central meetings and those with Dawn and Angie—it’s the agenda that helps focus time and understanding, and improves advanced preparation.
What level of communication works for you? A friend of mine commented on my software commenting style over the weekend, because I was the only person they’d known who actually used “emotion” and eloquent language structures in their code [†]comments. On the one hand, there is a big world of language out there, and it’s nice to be able to use it well and communicate richly. On the other hand, one doesn’t want to turn into Dennis Miller as the color commentator for Monday Night Football, making snarky or esoteric literary references that even your colleagues don’t understand, when all they wanted to say was that it was good that the guy in the blue uniform tackled that guy in the white uniform. Do people find your style amusing and intelligent, or obscure and elitist? This is an important question when you’re trying to do public outreach and engagement for the general population. There are lots of different audiences (faculty and students who receive awards, administrators who want to know effectiveness of campus cost sharing, people who stop you on the street and ask you questions about airspace utilization), and I want to learn how to connect with them all.
Is this where I mention that one of our primary ways of regular communication with our affiliates, partners, and friends is the INSGC Director’s Blog? I try to put together a new blog entry every month or so, and use it to communicate some of our strategic concerns and general oversight topics. Great, right? Except that Dawn told me a few days ago that people don’t look at the blog entries. (That is the point of website analytics—is anyone actually receiving the message you’re sending?) Well, if we never updated the blog, that would be the expectation. Or, if it was assumed that nothing important ever showed up there. But what if I said that the best way to see what we’re planning for (and why) will show up first, or best, or most explicitly, in that Director’s Blog? Would that get more visits? Perhaps, but the goal of the blog is not more visits. It’s to communicate more effectively with our constituents.
According to information theory (as developed by Bell Laboratory researcher Claude Shannon and MIT professor Norbert Weiner), communication includes a sender, a transmission channel, and a receiver. There have to be several effective elements of good communication: the sender has to send a message that is meaningful to the receiver; the channel must be able to support that message; there has to be a minimum of noise or signal loss to distort the message; there has to be enough redundancy of the message so that the receiver understands the intent of the message even if some of it gets lost. (This seems very tangential to the point of anything else relevant for Space Grant Directors. However, it’s actually part of my research background and training. For me, the analysis of communication effectiveness is a social and technical engineering problem, and not just a management or persuasion issue. Remember, the message is based in part on the context of the sender as well as the context of the receiver. I’m trying to explain more of my context in a more explicit way. Any resemblance to Dennis Miller’s football color commentary is accidental.)
So, what next? Over the rest of the summer, expect additional upgrades to our communications: not just in the use of the available technologies, but in our strategies, messages, and references. This is a critical point in Space Grant evolution, and I believe that one of the ways that INSGC will succeed in the future is to be a powerful and effective source of communication and documentation of STEM engagement in the State of Indiana.
[*] The specifics here are only to suggest that I have been a geek for a very long time. Some of you may fondly remember coding in FORTRAN, or even what a PDP is. If you don’t, just think of it as part of that quaint long-ago time when there were pay phones that people used coins to operate when they weren’t at home to access their permanently wired landline phone.
[†] Yes, these are the sorts of friends I spend my time with. We talk about styles of software comments, and mathematical models of information exchange in company meetings, and the use of multi-dimensional graphs to understand social dynamics. Don’t judge. It works for us.
Share this: