Recently in Project Managment Category

Anthropology and HR Rumors

| | Comments (0)

I was at an HRDC seminar and many of the usual work issues came up include perennial favorites communication and team work. We had some productive discussions, but one of the most fascinating was about the SRDP annual review process.

If you've been at Penn State for a while and ever talk with your colleagues you will get some great stories about the randomness of the SRDP (at least across units) and how people have gotten screwed (some stories may be exagerated, but some may not be). The good news was that the SRDP was handled fairly well at ETS.

Yet...our presenter made some comments and clarifications at the process that I had no idea were true. Lots of things we thought were "mandates" by HR (or were told were mandated by HR) turned out to mandates from somewhere else. No one knew who had crafted variations of the mandates or why they were done that way. The main point of agreement was that they led to a lot of confusion and frustration. And no one knew how to stop it.

Back at ITS Headquarters

I am writing about this because I was experiencing a phenomenon I usually am on the opposite side of. Whenever I go to parties, I hear interesting perceptions of our services including the fact that ANGEL was going away "next semester" twice in the past 7 years. For the record, I know it will be around for a while, but where do these ideas come from?

Ultimately, it's really an anthropology question. If you think about (and someone has), our homo sapiens tribes are evolved in much smaller groups than the Penn State environment. One theory (Dunbar's number) states that one person can really only maintain about 150 close personal relationships at once. Obviously we live in much larger communities (up to millions), but these large communities tend to break down into smaller subgroups for many interactions. Even in State College, we live in specific neighborhoods.

So...communication at this scale has many challenges and unique problems not faced at smaller scales. I think we all know this, but I wonder if we really appreciate it. We speak about using official channels for communication, yet evolution has really primed us for word of mouth. Maybe we shouldn't be so shocked that our messages get distorted by "gossip". Maybe we should be amazed when they get successfully transmitted at all.

The Ape in the Corner Office

I don't have an answer for rumor control. But I was reminded that one of my favorite work books was the Ape in the Corner Office. Although the title sounds a little barbaric, it really was a discussion about how employees (the herd) will often follow their primate instincts for both good and bad. Understanding them could help managers make for a happier herd (oops employees).

By the way, I don't think primatology has all the answers for improving work climate, but it seems easier to understand and forgive some strange behavior in ourselves and others when we think of ourselves as creatures of instinct as well as rational beings.

Collaboration: Really Letting Go

| | Comments (0)

A question a lot of us at Penn State struggle with is how to get buy-in from partners to work with us on our projects. I don't have any magic bullets, but I do have an interesting insight.

In Jan 2009, I became president of our local chapter of the Embroiders' Guild of America (yeah for me). This is an all-volunteer group, so if I don't get buy-in...nothing is happening. For various reasons, I was concerned with a sense of lassitude in the group. Membership had dropped, we hadn't held any community events in a while or even brought in an outside instructor. It's hard to stay motivated if you're not sure buying thread online is a good idea because of the economy. So I really wanted to invigorate the chapter if I could...but how?

As you can imagine, I did come up with a list of ideas, but ironically the best ideas had nothing to do with me. Soon after I became president, a group proposed a workshop in a technique I was not too fond of with someone I was not sure about. But...I could tell that there was a core group of the membership who really wanted this. So I initiated a workshop exploratory committee.

As you may have guessed, we did hold a workshop and it worked out well. Not only did a lot of people attend, but a lot of the group helped in the organization. We got some really good ideas about where to hold it, how to get funding, what to feed people during and where to eat dinner afterwards (one of the few original ideas I actually had). It was a lot of fun...and we're already planning another one (started by someone else).

My lesson was that the collaboration may be more important than the idea. We do have lots of great ideas here at ETS like Media Commons, e-Portfolios and the Educational Gaming Commons, but so do a lot of other folks. Some of our best and most beloved projects have come from suggestions/demands from the "people". For instance, I remember a time when instructors were doing blogs with "extralegal" platforms. We really needed the Blogs at Penn State project to catch up with them, but ETS has made it so much better.

There are lots of ways we can get "our" projects done and that can be a good thing, especially if we want to demonstrate how technology can be transformative (seeing IS believing). But, if we really want partnerships, maybe we need to figure out ways for our partners to tell us what they want. Who knows what they might come up with?

Role of Small Projects in the Educational Tech Ecology

| | Comments (0)

A question that comes up frequently in ETS is what sorts of projects we should take on. I think it's a given that supporting university-wide services such as ANGEL, Blogs at Penn State, and Media Commons is crucial.

So is supporting projects for large-enrollment courses such as STAT 200, SPANISH 1-2-3, ENGL 202C, BIO 12/4/2 and so forth. It's great when one project can affect improve education for hundreds of students.

But what about smaller projects? Should the still have a place in ETS? You probably won't be surprised that I do think we should consider projects for smaller courses in some cases. Although large-scale projects are extremely important, I do think there are lessons that can be learned from smaller-scale projects.

  1. Smaller projects allow for experience with non-scalable tech. A lot of of the newer technologies don't scale well...at first. Yet if we try them with smaller student populations, we might get more experience with them and be more prepared for when the tech hits prime time.

  2. Larger classes have more resources. The Spanish Basic Language Program transition to online learning has been a stunning success...but it relies on a dedicated tech-support person to support it across all the sections and instructors. Few small courses will ever have anything approaching this level of support. I think we all know this subconsciously, but if we at ETS only deal with large courses, we can be lulled into thinking a typical instructor has more resources than is really available. Been there, done that.

  3. Small classes provide good examples of how to use technology. When I am looking for examples of how to use a new form of technology in different ways, it usually comes from a smaller class and an instructor who has tried it out on a smaller scale.

  4. Advanced classes are smaller classes and advanced classes usually have more higher order learning goals. Although it's important for ALL classes to include chances for reflection and analysis, sometimes it's the case that a student won't have the prerequisite skills or knowledge to perform at the highest learning objectives - that may come in a later semester (in a smaller class). More advanced classes may also require interesting tech that a lower-level class may not need...yet.

  5. Most classes at Penn State are smaller classes. They may not have the TA's or even the podiums to use. How can these classes all be improved? The Teaching Learning Assistant program is a large-scale program that can help many instructors, but it assumes a limited tool set and limited use of the set. Experimentation may or may not be possible.

The list above explains why I think it's nice to have smaller projects in the mix, but even I would admit that we still have to be careful on how to maximize our bang for the buck. I do think it's important to consider 1) How outcomes can be shared, 2) How to encourage instructors we work with to share within their department/college and especially 3) Templatizing new tech. If we build an innovative quiz, media exercise, game or presentation format for one instructor, can we expand its range for other disciplines? Interesting issues to ponder.

I will share one resource sharing story that surprised even me. Several years ago two of us at ETS worked on an animation for the heating of supercritical fluids At the time, it sounded fairly obscure and I admit that the instructor had to spend quite a bit of time explaining the concept enough to us so that the team could get it built. But...lo and behold, several years later, the concept re-emerged at a different campus in a different course in a required course for a large group of engineers. The second instructor was quite happy to see that we had this animation available.

Although it was one specialized animation...it really did have the potential to impact more students than we would have guessed.

What this Inquiring Instructional Designer Wants to Know

| | Comments (1)

An ongoing discussion we have had at ETS and in the instructional design community has been how to communicate what we are doing. We have discussed different tools, communication flows and how many times we have to do it. But I am not sure we have discussed what information we need to know and why.

What and Why

Speaking from a purely selfish perspective, I am most interested in any information to answer any question a faculty member might ask. The key here is that an instructor may ask anything at all related to technology. For instance, last summer I spent most of my time developing an online course. But when the ANGEL/Blackboard merger was announced, I spent about 15 minutes my course instructor explaining that ANGEL was not going away any time soon and that Penn State would have a plan.

I knew key reassuring details because I bugged Jeff (thanks dude) and listened to the chatter on ANGEL message boards. Similarly, if an instructor asks me about blogs, I do give what information I know...then point them to blogs@psu.edu. However, being able to answer some questions has some benefits. One is that it might save the Blogs Support system another redundant question. The other is that it allows me to build some credibility with my faculty client that I do know "technology." Strange, but true.

Finally, I tend to be interested in hearing about other projects so I have examples and strategies I can share on new projects. It's also good to learn tips on what works and what to avoid. Surprisingly, I am interested in technologies that I'm not necessarily using yet. For instance, I have yet to be involved in any clicker courses...but you never know when that could change or if a clicker question will be asked or if I realize that clickers could be darned useful for a new project. I'm just saying....

What isn't so important

Not to be snarky, but most of the information found in weekly reports aimed at managers is NOT that helpful. First, your manager pretty much knows what you are doing project wise - you don't have to explain what the TWT Certificate (or whatever) is every week. I, on the other hand, may need a project catchup. Second the report is more focused on listing what as accomplished, sometimes at a microscopic level (how many consultations, what focus group was completed, when the next phase will be completed).

This IS important to the organization, and I have no objection to giving it and sharing it (and I even skim it). But am I surprised that no one besides my manager is getting back to me on a project? Not really. My to do list is just not that exciting...

How?

This has been tricky. What I want is a forum where questions can be asked. In the past we had done round-robins in some meetings, but if everyone is zoning out even I agree that it's not so effective. I do like that some meetings have evolved more into giving demos, and I hope this trend continues.

The problem is that if people aren't interested in a topic, then attendance may be too low for a presentation to have an ROI for the presenter. So we can perpetuate a pattern that we live in our silos. But now that I think of it, this may be a problem that is beyond my control...

Obessed with Documentation?

| | Comments (0)

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!

Another Crucial Conversations Review

| | Comments (1)

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.

A Formal Study of Online Social Loafing

| | Comments (0)

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.

Facilitating Cross Unit Communication by Mixing Levels

| | Comments (0)

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.

LibraryComm.png

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.

Behold the "Punch" Meeting

| | Comments (0)

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.

What's your Personal Brand?

| | Comments (0)

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".