ConTeXt

ConTeX

Recently at GIBS I have been involved in a number of assignments and projects. This is nothing new to me, having been involved in similar instances during my engineering undergraduate (the tangible difference being content). As I think most people would agree, individual assignments/projects are preferred. They afford you flexibility in how you allocate your time schedule. There is no real argument over content, and the language flows easily in a single voice. The intent of this post is not to argue the pros and cons of group and individual work. Rather, I wish to explore some of the group work issues that I was recently exposed to. (Disclaimer: this is not particular to my group, in case they end up reading this).

Split the Work and Separate the Group

So, if a project has a number of main sections that are not truly linked, the natural instinct is to assign work to a smaller group or individual. I think the belief here is that work done by the individual, who may be more qualified, is likely to be of a higher standard and produced faster. I liken this to an assembly line. This actually seems counterintuitive. The whole point of a group project is to collaborate, debate or argue, and establish the collective ideation. To most people, this seems tedious, and so we split in an effort to avoid conflict.

I think most people have been exposed to "think tank" or "incubator" situations where ideas bounce off people, information flows freely, and something evolves organically. These are the types of group encounters that truly work. Often this occurs with friends or people that we are more comfortable with. But, because we cannot always choose our team, we subsequently choose to silo workloads to avoid perceived future conflicts. This is in my estimation.

Lost Collaboration and Split Flow

So now that the group has been split, the issue is that project work DOES overlap (why would it not?). To remedy this, each individual or subgroup presents their work to the group. Often, the group is under the illusion that the project is more or less complete and must be assembled into the final product (be it a document, mechanical assembly, software package, etc.). Here is where we try to bury the bodies. We try to take the individual puzzle pieces, that have been made by different puzzle manufacturers, and we attempt to piece them together. Inevitably there is a lack of argument cohesion. To better illustrate what I am trying to say, consider the images below.