In modern engineering, if you cannot work in teams, then you cannot design.
The amount of expertise and information necessary to execute a typical design in modern engineering is far more than only one person can know. Also, the time-lines for bringing products to market is such that one person can no longer do all the work themselves. Even so-called starchitects have dozens of assistants. Thus, it is necessary for design engineers to work in teams. In a recent survey of 33 engineering companies across North America, teamwork was identified as one of the top three skills needed by graduating engineers [Var95].
However, in academic settings, a poorly formed team can unnecessarily and unfairly lower students' grades. We resolve this conflict by carefully forming teams, providing as much support to teams as necessary (something that isn't available in real life), and assessing projects in ways that can distinguish the contributions of individuals.
The goal of the semester-long design project is to expose students to a semi-realistic design situation involving an open-ended design problem that must be solved by working together.
When you enter the workforce, your employer will not ask you who your favourite co-workers are, and you will not be allowed to work with your friends. You will be told who to work with, and your future with the company will depend significantly on your ability to get along with your colleagues and behave professionally. In order to give you some experience in this, you will be put into teams by the instructors.
Once a design team has been established, it will not be changed as a result of friction or other personality problems among its members. The members themselves will have to find ways to resolve their difficulties, just as would happen in real life.
Of course, your instructors and teaching assistants will be available to help overcome such problems – something that is rarely possible in real life.
Finally, the people skills you develop by interacting with your classmates will better enable you to handle various other social interactions outside your profession. Teamwork is more of a life skill than just an engineering skill.
Design teams will be formed early in the semester by the instructors.
You may either be instructed to take a personality type indicator, or to self-organize into teams. Details of how to do this will be provided by your instructor.
“Personality tests” are quite common in industry. They are not tests in the conventional sense – no one can fail a personality test. Rather, these tests identify the basic personality characteristics of an individual. Having those characteristics in hand allow managers to build teams composed of complementary members.
Because these kinds of tests have been shown to lead to teams that work better together, they are often used in courses that include team-based projects.
“Collaboration is a conscious, learned behaviour.” [AGK92] One would reasonably expect, then, that collaboration takes time to develop, and that any change to the members of a team will require some re-learning.
Whenever a newly formed team works together, there will be a “settling in” period during which each member will become accustomed to the work habits of the others and become comfortable with the team as a whole. Here are some notes designed to help assure you that teams mature over time, and that this is not only normal but also expected and accounted for by your instructors.
“The efficiency of collaborative teamwork depends on the team ability to exchange knowledge for continual learning and to develop shared mental models.” [FKL09] This means that more than anything else, you have to be willing to accept your teammates as your equals, no matter what, and to reach a point where you really, deeply agree on the knowledge and information you're using for your design work.
“Successful engineering teams may find their greatest challenges occurring during the early stages of their existence.” [NZ98] This means you need to be attentive to the differences between you and your teammates, and recognize that these are almost always temporary. Still, if you want your team to “gel,” you will need to work together and see past the differences.
You may feel strange when you first meet with your team. This is perfectly natural. In fact, there are generally four stages through which any team passes before really fitting together. It helps to know what those stages are, so that you know there's a light at the end of the tunnel.
Many teams in real life conditions never survive Stage 2. The instructors are available to make sure you can overcome any hurdles that come your way.
A good team is one in which:
Certain kinds of behaviour are expected, professional, and extremely productive during collaborative work meetings. These include:
Successful teams also depend on features of the “organization” (i.e., your instructors and teaching assistants). These include [NZ98]:
Still, this is a university, not business or industry. There are limits to what can be provided to your team in an educational setting. Your instructors will do whatever they can, within the scope of good teaching and learning practice, but be aware that they cannot do everything you may need them to do.
A real-life design team is composed of a wide variety of experts. Each one brings a specific and unique perspective to the problem. Every perspective is valuable; but sometimes, perspectives can clash, as can be seen in the image below.
Remember: your team mates mean well; they are doing their best to communicate meaningfully with you. Your job is to meet them half-way and remember that their perspective may be the key to solving the design problem at hand.
Another important aspect of communication is to keep a design journal.
Sometimes, teams just don't work right. If your team is having difficulties getting along, or if some team members aren't participating, or if you are falling behind in your schedule, read about team remediation. Do any of the issues raised there apply to your team? Sit down with your team, and discuss all the various topics below, and look for possible solutions. Every member of the team will benefit if the team as a whole functions better.
Also, bring your problems to the attention of your instructor as early as possible. Do not leave these problems to the end of the semester; by then, nothing can be done to make up for lost time and effort.
Sometimes, a student will drop the course and leave their teams short a person. This is inevitable. The question is, what should the remaining members of the team do? Here's a list:
If in doubt, students must contact the instructors for further guidance.
Many people talk about collaboration these days, as if it were a silver bullet for a successful design project. It isn't. There are times when collaboration is very helpful, but there are other times when collaboration can actually harm a project. That's because there are three kinds of teamwork, which are distinguished by characteristics of the team itself and by the nature of the project. Depending on circumstance, only one of the three types of teamwork is most likely to work best.
Just working together (as in the image to the left) may not be a good thing in the long run. While this is clearly coordinated work, one must wonder if it's true collaboration - especially for the poor schmuck installing the air conditioner. (Nonetheless, please note the correct use of a free-body diagram.)
When a team works by coordination, each team member has a clearly defined role (e.g. one person deals with mechanical issues, another deals with electrical issues, and so on), and there is well-defined management/leadership directing the team's activities. This is a very efficient way to run a team, but not very effective. That is, if the design project is clearly understood (e.g., the team has significant experience working together and knows well the kind of product being developed), then coordinated teamwork will get the job done most efficiently. However, if the design project is not well understood, or if the team lacks experience, or if the design problem is poorly defined (which happens more often than you might think), then coordinated teamwork will not work well because it cannot adapt to the dynamic nature of the situation.
In course projects, it is unlikely that the conditions for successful coordinated teamwork will occur except perhaps at the very end of a project, after the team has worked together for some time, and the instructor or teaching assistant is providing leadership. In most cases, however, coordinated teamwork is inappropriate in scholastically-oriented projects.
When a team works cooperatively, each team member has a clearly defined role, but there is no defined leader role. That is, leadership is equally shared and distributed among the team members. This kind of teamwork is not usually as efficient as coordinated teamwork because there is no “management structure,” but it is more effective than coordinated teamwork because the lack of management structure makes the team more adaptable to circumstance. If there is vagueness in the project definition, or if the team lacks experience, then cooperative teamwork is usually better suited to a get a successful outcome. In cooperative teamwork, the team as a whole allocates work to individuals based on their roles, and do not need specific direction from leaders to get things done. This requires team members that are willing and able to understand their teammates points of view, roles, and responsibilities.
In course projects, cooperative teamwork is useful in roughly the latter half of the project, when the team members have come to understand the design problem well, and have gotten to know their teammates reasonably well.
When a team works collaboratively, there is no leadership and there are no pre-defined roles for the team members. That is, not only is leadership shared by all the members, but any one person should feel free to contribute to any element of the project, without fear of “stepping on the toes” of his or her teammates. Collaborative teamwork is the least efficient but most effective form of teamwork, and it is best suited to situations when projects are poorly defined (which usually happens at the start of any project), or when the team is composed largely of novices to the kind of project being undertaken. In collaborative teamwork, roles might be allocated but can be changed at a moment's notice depending on the needs of the project.
In course projects, collaborative teamwork is ideal for the early parts of the project, when the team members are still getting to know each other, and when very little is really understood about the project itself.
Here's some general hints on keeping your team running well.
Do not fear chit-chat before/after meetings. It's well-known that work environments that permit casual conversation between workers leads to better productivity overall. Of course, you don't want to waste actual work time on idle chit-chat, but leave yourself time for that sort of thing before and after your meetings.
…individuals who talked to more co-workers were getting through calls faster, felt less stressed and had the same approval ratings as their peers. Informally talking out problems and solutions, it seemed, produced better results than following the employee handbook or obeying managers’ e-mailed instructions1).A. Greenberg, Mining Human Behavior At MIT, 2010
Don't have a leader/manager. Leadership & management skills need training and experience that you don't have. Don't let one member “take over” the team.
Do share leadership responsibilities by task. For instance, the person intending to claim full responsibility2) for, say, requirements may well be expected to manage that part of the project. Base these decisions on team consensus.
Don't ignore a part of the project just because someone else said they'd do it.
Do be willing to check and comment on every part of the project.
Don't delete the work of others without complete and honest agreement by everyone. If there is resistance, move the work to an Appendix and note is as a failed attempt.
Do build on the work of others and enhance each other's work with your contributions.
These observations about teamwork has implications for how students should work on team projects. Based on the descriptions above, it should be clear that typical design projects should start as collaborative works, but end as cooperative works. This means that teams need to regularly stop and assess where they are in the project. It is not as simple as working collaboratively for half the project, and cooperatively for the other half of the project. The team must reflect on their activities and decide based on circumstance whether it is time to switch from one kind of teamwork to another.
If the roles of a team's members are changed or realigned, members may experience anxiety, uncertainty, and frustration which, in turn, promotes a reverting to dysfunctional behaviours. [AGK92] This is one reason why we strongly prefer to establish teams as quickly as possible and keep them fixed for the duration of a project. Whether the project is occurring in “real life” or in a course, the burden of team dysfunction undermines achieving project goals.
The boundaries between responsibilities, roles, groups, etc. are often a function of boundary objects - things or systems or processes that enforce a separation between the entities that need to “work together.” Some examples include:
Boundary objects are usually assumed to be static and immutable, but they can be changed [FKL09]. For instance, email is a boundary object that can keep team members separated in time and space. While this separation may be beneficial in some cases, it can lead to lots of problems too. (For instance, too many emails in one's inbox, too many document versions attached to those emails, weaker depth of communication when done asynchronously,….)
However, one can change the boundary object and thus change the nature of the teamwork. Say one changed from using email to send MS Word documents to team mates, to using Google Docs. Google docs allows multiple users to simultaneously edit a single copy of a document. This supports a boundary in space, but allows teammates to work simultaneously, which tends to increase the richness and depth of the collaboration.