I participated in a collaborative project for a web programming class last year with three other people. Our personnel inputs, although we were all information science majors with programming backgrounds, consisted of different skills we brought to the table. One person was better at design, one at interactive programming, one at databases, and one at writing up the report. This functional diversity in skills made us really efficient at breaking up the workload in the processes part of our collaboration. None of us had prior experience working together, but it was a small enough group that it was not hard to learn each other’s strengths and weaknesses. Our task was the production of a website for a local business and learning to work with others on a larger scale project. This cooperative task could be categorized to the “generate” quadrant of McGrath’s Task Circumflex, including both planning and creative aspects. Tools and technology we had to work with included servers and database technology as well as books and other sources to look up how to do certain things.
Our interaction consisted of a series of emails deciding when to meet up, meeting to plan out the next part of our project, dividing up the work and programming individually, and finally meeting again to check in or to combine our work. There was definitely a certain ease of coordination when we were planning face to face rather than over email and it was definitely more efficient. The group showed conformity in the informal style of our emails as well as in the style of our meetings when we met face to face, showing that proximity was not an obstacle for conformity to group norms. Our roles were clearly outlined from the beginning based on our skills and preferences and seemed more defined when we worked individually and emailed rather than when we met face to face and worked as a whole group. While strategy was minimal in our interaction patterns, there was a certain amount of responsibility for each of us to have completed our part of the assignment when we met to turn something in. Here, proximity increased contributions and helped our group accomplish our production goals.
In the end, we produced a really satisfactory, usable website and a good description in the project report, which were all part of the production output. Finally, I think our group worked in a very cooperative way, building off each other’s ideas and skills instead of shooting people down. Because of this, I think all of us would work together again and I have already worked with two of them on other things since then.
Subscribe to:
Post Comments (Atom)
Posts
I haven’t had any experience designing a website like this quite yet (but I will this semester), and I was wondering how often you had check-ins and Ftf meetings. Did you combine things in steps or did you have one, giant meeting at the end of the project? I find this is sometimes the case with projects, often regardless of the scope. In either case, Ftf meetings are always a good idea because they build cooperation and let members shoot ideas off of one another, regardless of their roles in the group. I'm glad everything worked out for your group.
ReplyDeleteYour strategy sounds like one most groups I work in try to adopt. Sometimes it seems to work well, but sometimes when the group is too big or there's too much work to get done, I find that it's difficult to ensure productivity with just check-up meetings. When I was in a group of 7 on a big project, just meeting FtF to check in with each other wasn't efficient enough - we actually had to schedule work time to sit down and all work in the same room.
ReplyDeleteIt sounds like your experience with just a 4 person group worked out pretty well - it's hard to balance the number of people versus the trouble of coordinating everyone, but 3 to 4 people seems to be ok. I guess what I liked about having 7 people was that with that many people, there was at least one person I got along with and worked well with.