As I promised in an earlier “how-to” on using Google Sites for team projects, this post is a response to Dylan Salisbury’s  request for discussion around the roles for a project team.  While he suggested two roles, I’m going to extend to four.  He suggested:

Team leader: Responsible for making sure work is fairly divided, meetings happen, members are aware of what's expected of them, and any executive decisions that need to be made.  (Of course it's still great when decisions are made by consensus.)

Document editor (one per major document): This person is responsible for assembling everybody's work and for high and low-level consistency of the document.  This person needs to be very quick on communication and editing near the document due date.  In a time crunch, this person has authority to make editing decisions or rewrite someone else's work.

 As a professor, I’m thrilled to see a goal of ensuring consistency to a project that has piecemeal characteristics. If this particular task is left out it shows – in class projects or any other group task.  My contribution here is to push for a broader consideration of the team roles – one more focused on the overall behaviors needed for effective performance. 

Ketrow (1991) notes that effective teams cover three types of roles.  People who can do the task itself (e.g., ship builder, computer programmer, statistical analyst).  These people are the reason the project is being done.  Then, given it’s a group project, you also need to organize the process (procedural facilitation), and to make sure the knowledge of the team is made available (socioemotional facilitation).  The best person/people at the task are not necessarily the best facilitators.  In fact, you may not want them facilitating if you really need them focused on the task.  The team leader role above seems to be a combination of the two facilitation roles.  That’s fine if you have one person on the team who can do both (both be organized and be effective drawing out all the needed knowledge from the other team members), or you may have co-leaders.  I’d put the document editor role down as a critical task role.  You may also have critical roles assigned to the accounting expert, marketing guru, etc. depending on the nature of the project.  A strong suggestion: If you are trying to learn from this work (be it in class or on the job), yes, have the expert in accounting in charge of the accounting portion of the work – but also have the weakest person in accounting in a support role to that expert.   

What about the technology? As noted in the prior post, an early discussion about the role technology will play in the project is key.  Ketrow’s work was before the age of wikis, blikis, and blogs.  You may find value in extending the three role format (procedural, socioemotional, task) to include a fourth: technical facilitator (sometimes call a “chauffeur.  You may also find value in seeing how you can off-load some of the procedural and socioemotional tasks to technology tools.  Anonymous brainstorming may overcome the need to have a socioemotional facilitator in the mix for some tasks.  To-do lists with “tickler” may take-on the reminder role often played by the procedural facilitator.

Overall, think carefully about:

  • How you meet (face to face or electronically)
  • How you store your work product and manage versioning
  • What are the response time expectations – are their family or work obligations that block certain days for certain people  -- calendar these. 
  • Individual responsibilities
  • Team expectations and timeline for feedback and adjustments.  No team is built perfectly from the start -- you don’t know your resources or needs well enough.  Set aside time to renegotiate after the first few weeks.

Please feel free to add additional questions, suggestions for tools or processes, or roles that you think make a critical difference.  I’m especially interested in how you have best managed the discussions around team expectations and feedback.