Recently in Project Managment Category

Those of you who have been working with me a while (say a month or more), know that I care very deeply about documentation...maybe to the point of a (minor) obsession. But how and why did this happen? Do I derive any benefits from this? Does the community? Let's discuss:

My Testing Notes

A lot of documentation happens because I am attempting to explaining something in a way that is comprehensible to me. For instance, when I first began exploring the wonders of Unicode and Accessibility, I encountered a lot of information which told me what to do but not HOW to do it.

For instance, in accessibility, a common recommendation for rollovers is "Use stylesheets". OK, but ... could you be be more specific? Is there code out there I can borrow? Back in 2001, it was hard to find good resources, so yes I tested (a lot) and I have shared (see http://webstandards.psu.edu/accessibility/tech/rollovers).

Now if I can get stuck, I can copy and paste the code I need. This is one reason why there is so much parallel documentation out there - the "official" documentation isn't providing enough detail (or the right kind of detail).

If You Mandate...Please Provide a Path

This leads me to my next point is that I believe that if I make a recommendation, that I am obligated to point you somewhere which tells you how to accomplish this (even if the recommendation is to hire a programmer).

For instance, if I recommend using Electronic Reserves in ANGEL, I know I can point users to either http://angelkb.ais.psu.edu/article.asp?article=1325&p=2 or http://www.libraries.psu.edu/psul/reserves/angel.html for the how-to. Because, if I don't, who knows if the instructor will take the time to figure it out?

Unlike a video game or cruising iTunes, I'm convinced instructional tools are generally considered work tools for many instructors and not something you want to spend time "exploring." Hence I do tend to structure docs in small just-in-time pieces which are optimized for searching (if not browsing).

Build it and They Will Come

I've been involved with "growing" a number of communities, but honestly the most "action" I get from the outside world is (ahem) the Unicode information. A lot of times it's to correct a typo, but sometimes it's a request for more information (the answer of which may get incorporated into the site) or just new information. It is more collaborative than it first appears.

On a slightly higher level, building decent, comprehensible instruction does lend your site an air of trustworthiness. If you can write material people can understand, you probably know what you're talking about. As a result, I do get some interesting referrals from time to time.

Room for Improvement?

Of course there's always room for improvement. For instance I always struggle with how to connect the pieces I have scattered about. I had one person looking at the Spanish accent code page ask if I could develop one for French. Clearly the navigation wasn't working for that person...

Another struggle is to satisfy all audience needs. Some people need all the details, but others find it overwhelming. Some people need video, and others get by on reading with images. I know I skew in one direction, but is it always the right direction?

And finally, I have to confess the other reason I love documentation - I'm good at generating it. I say with this with the humility of someone whose ITS Training attendees give so-so marks for presentation but very high marks for the written documentation.

It's at times at these, that I am grateful I can point confused students to quality documentation!

Today I completed most of the "Crucial Conversations" program, but this time led by ITS Training Manager Lisa Lacombe. I have to say I found both Lisa and the program very worthwhile...which is saying a lot because I am a professional cynic when it comes to this type of program.

I admit that I have had my issues where I say the wrong thing, in the wrong way at the wrong time. I've been aware of it for quite a while, but, despite numerous trainings, have never understood what the real problem is. Fortunately, the authors have developed a framework which actually makes sense to someone like me. My favorite paraphrase:

When your emotions fly, the blood rushes to your muscles [as you prepare to defend yourself], and it has to come from somewhere...and that would be your brain. If you're acting like an idiot, it's because at that time, clinically you are an idiot.

It does explain a lot. The rest of the program has some suggestions on how to hold better crucial conversations (e.g. paraphrasing, active listening, and some other interesting ones). I especially thought the video vignettes were very realistic, up to an including the confusing advice often given out by other programs trying to help difficult employees. The same actor could be doing good in one video and bad in another - just like real people.

But, I think the most valuable part of the program was the empathy for the "problem children" (both the authors and Lisa). While not taking away responsibility to have better reactions, the program does explain that some behaviors are instinctual extensions of primal emotional instinct not an evil plot to ruin a co-worker/employee/manager's day. I would recommend this both for "difficult people" and their colleagues. I think both can learn a lot about how to avoid bad interactions.

I have a lot to think about, and am curious if it will take. If nothing else, I think it will give me a better way to troubleshoot past errors.

An important, but not always acknowledged, aspect of team work in social loafing or the tendency in some individuals on some teams to slack off and let others fill in the gaps. I think we've all experienced it from either end.

It's not a pretty aspect of team work, but since it can impact overall performance, I'm glad there is research on this topic such as this article on social learning on online student teams. If nothing else, I think it gave me some real insights on why some conflicts seem to recur on almost every team and what I may be able to do to mitigate it.

In the "Literature Review" section, the author pointed out some findings from non-online teams, namely that:

• Effect of Size - The larger the team, the larger the temptation to loaf. A smaller team may have more productive members than a large one.
• Distributive Justice - Members who felt they were more likely to share in rewards and recognition were less likely to loaf.
• Sucker Effect - Actually more like avoiding being a sucker. If a team member senses that they may be "stuck" with a lot of additional work from a social loafer, then that person will become resistant to taking on too much work (possibly to the point of loafing).
• Task Visibility - Members who felt that outsiders (an instructor, supervisor, audience) were more likely to examine the final product were less likely to loaf.
• Dominance - If a team leader or dominant team member devalues a member's task/position/contribution, then loafing is more likely to increase. Interestingly, this can lead to a feedback loop because Dominant Person A can either try to do everything or assigning task elsewhere while Person B starts to loaf and gets a reputation of not being able to perform.

Do these sound familiar? They do to me. I think there are strategies a team leader can take to mitigate these such as making sure recognition comes to the entire team, taking on largish tasks if possible and understanding and acknowledging every member's contribution (and maybe bring cookies every so often). Instructors in courses can build anti-social loafing strategies into team tutorials.

To these, I would also add that if you feel that some is "loafing", it may be important to check with that person if something you don't know about is going on. I remember scheduling a weekly meeting that a student was always late for only to find out he was leaving class on campus and trying to get downtown in 10 minutes - Oops.

I think the one thing that does NOT work is asking people to be "a better team player" without acknowledging that social loafing is a real and ever-present hazard of team work and a major source of conflict.

P.S. - I should point out that I think many of these findings assume that many team members are more extrinsically motivated (looking for external rewards) than intrinsically motivated (doing it for the love of it), but I think many teams in school and work are powered by extrinsic motivation. We can't love all our duties/courses equally.

A common theme in these parts is enable different areas of Penn State to effectively work together. I have been on a few projects where cross-unit projects which have come out reasonably well - the products are still in use, and I'm comfortable communicating with previous team mates.

I think the secret is that there is a crucial mix of top-level and bottom level communication. The top levels (the deans/directors/provosts) were important in establishing the importance of the project. In project land, this often corresponds a kick off meeting to establish main parameters (deadlines, budgets, staffing, etc), but afterwards that person may fade out except for extreme emergencies.

On the other hand, the bulk of the project communication happens below the top level at the project manager level. These are the people who will be implementing the project who need to talk to each other in a regular basis to resolve different issues. If you look at the diagram below of a cross ITS-Library project, you'll see lots of horizontal arrows across units and some vertical arrows within each unit. The key is that the implementers need to know who to talk to within the other unit.

This seems fairly straightforward, but a lot can go wrong to derail this structure. One of the worst of them I think is mistiming of the kick off meeting where people are introduced to each other and the scope of the project. If it happens too early (before majority of project members come on board), then late comers may feel left out of the loop. If it happens too late or not at all, then the implementers may not have enough confidence or knowledge to formulate a viable project plan. It's amazing how much time can be wasted because no one is sure what the original project intentions are.

Yet if the top-level is too involved I think two bad things can happen. One is that the the top level can feel frustrated at being committed to one project when many other decisions need to be made. The second is that if the implementers don't feel comfortable contacting each other directly, the rate of progress can slow down quite a bit.

I suspect a lot of directors know this, and look forward to the days when implementers can self-organize...but it hasn't happened yet. Why? I will be cynical and say that it's because implementers can't make the key decisions needed to self organize.

I may have a great idea, but can I convince another busy soul to tag along when he or she is already booked 40+ hours? I certainly can't offer the kinds of incentives offered to other busy people like buying better software, an iPhone, generating publicity or a good staff review...because I'm just not a manager. In terms of collaboration, I'm limited in what I can promise on my own without top-level involvement.

Personally, I think the mixed model is fine already. It's a model I wish were followed a little more consistently.

Instructional designer Stevie Rocco invented a great term for the perfect meeting - the short (but frequent) "punch meeting". I try to squeeze these in to most projects (like Blended Learning Courses).

It should be noted that the initial meetings on a project are as long as the other "lengthy" meetings we may not be so fond of, but, believe it or not, they rapidly shorten in only a few weeks. Sometimes you can skip to phone meetings, e-mail and canceling meetings. Like a miracle of nature - you will begin to "gain" time for "real work".

To me the key is frequency. If you put them off too long (e.g. once a month), issues tend to build up and people forget things - it's not nearly as productive.

It also leads to the other dreaded type of meeting - the emergency "pop-up" meeting. These are the ones where your serene work flow is interrupted by yet another crisis requiring your immediate attention. You can't avoid all of these, but maybe the punch meetings can knock these down to a more manageable number.

I've been viewing a training video on Web design project management that my colleague Audrey Romano suggested and I ran into an interesting concept that I think will help me understand navigating personnel dynamics in future projects.

The training was from Kelly Goto who had been a keynote speaker a few years ago for a Penn State Web conference. At the time she had mentioned the concept of "branding" which I admit I equated to making sure we had all our logos in the right place and stuck to variations in the blue and white palette. In my defense, I had to leave her presentation early.

But this time, I got a better idea of what she meant by "branding" which is that you want to present products and services which genuinely reflect your corporate philosophy. For instance Penn State has always represented quality for value to me. That is, even though Penn State is dedicated to serving the state of Pennsylvania as a lower-cost "public" institution, it has always maintained a world class curriculum in many specialties. This is why a "Penn State" degree means so much.

I have to say that growing up in Maryland, we were always a little more impressed when an out-of-stater was able to get admitted to Penn State and had a choice besides the University of Maryland (although that university has improved a lot academically).

When thinking about Penn State employees, I think it's a safe bet that almost all of us do appreciate the Penn State "brand" and want to make sure that it's never degraded in any way. Interestingly though that can be a source of conflict as well as harmony, because we all have different ideas of what "protecting the brand" means.

This is where I think the concept of "personal brand" or "reputation/values" is important. For instance, some of us want to be as innovative as possible, but others want to be as secure as possible. Similarly some people want services to be as flexible as possible, but others want them simple and easy. Or maybe you discuss whether documentation should be "detailed" so it can account for different scenarios or just present the facts in a easily digestible manner. All of these are important considerations, but unfortunately they usually can't all be satisfied all the time. So we have to negotiate (and some of Penn Staters negotiate more effectively than others).

I think I know what my brand is, and it's probably straightforward, persistent, systematic and in-depth (I can give you plenty of specific examples if you just ask). I'm also all about the flexibility to accommodate all valid learning objectives.

Alas though...it's rarely "easy going".