The Rolling Learning Cell:
A Method to Integrate Individual Assessment and Team Grading Components in Information Systems Curriculum Team Projects
David L. Russell
drussell@wnec.edu
Janelle E. Goodnight
jgoodnig@wnec.edu
Western New England College
School of Business
Springfield, MA 01119, USA
Abstract
The use of teamwork in the IS profession and in IS education is common.  However, significant differences exist between professional teams and teams in IS education.  Existing practices regarding teams in IS education often do not prepare IS students well for their future roles on IS professional teams.  Ironically, this is because teams in IS education model professional IS teamwork too well, particular with regard to their reward structure. Simultaneously, teamwork as commonly implemented in IS education reinforces student strengths and does not address student weaknesses, particularly with regard to the various roles that exist in teams. Here a teamwork method, the Rolling Learning Cell method, is proposed that addresses present weaknesses in the use of team in IS Education. The model is well grounded in the research on the use of teams in higher education.  The method emphasizes specific and rotating roles for students to exercise a variety of teamwork skills, while maintaining the concept of a final project done by the whole team.  This method has been successfully implemented in other areas of higher education.  A pilot study on the use of the Rolling Learning Cell method is included.
Keywords: teamwork, teams, team roles


1. INTRODUCTION
Information Systems (“IS”) professionals frequently work in teams, now more so than ever.  In some cases, the team is made up of IS professionals undertaking a major task.  In other cases, perhaps the majority, the IS professional serves on a multi-disciplinary team working on a large-scale system serving a broad constituency.  In the latter case, the IS professional often serves as more than a representative of the IS department: rather, he or she serves as a consultant.  The day of a diligent programmer, working in isolation, has passed.  It follows, then, that students aspiring to be IS professionals should learn to work in teams and that teamwork should permeate the IS curriculum. We put forward, however, that in this respect IS professors are not providing adequate direction for students working in teams, for a number of reasons.
2. TEAMWORK DISCUSSION
2a. Teamwork in the IS Profession
In most industries, the evaluation of teamwork is usually collective (Myerson, et al., 1996) without effort being made to discern individual effort and contribution; Myerson call this practice the “temporary group”.  This level of evaluation is paralleled in IS education by the giving of a “team grade” that is altered for an individual team member rarely and only upon significant evidence that an individual student’s work is far superior or far inferior to the efforts of other team members.   Che and Yoo (2001) develop this concept into a theory, arguing that teams foster cooperation and mutual support among employees, but at the cost of increased complexity in remuneration and incentive.  In particular, they note, corporations are abandoning the former “zero-sum” reward system and replacing it with a joint evaluative system that is particularly effective when using team structures repetitively.
Teamwork involves much more than working on a team.  It involves, instead, work in a variety of roles that team members undertake.  These roles include, among others, leadership and vision, detailed planning, the actual technical work to be undertaken, and the recording, documenting, and reporting of the work achieved. At any time, the IS professional may find him/herself in any one of these roles.  The IS curriculum must prepare students a wide variety of teamwork roles.
2b. Teamwork in IS Education
This paper presents an alternative teamwork method.  This method is in marked contrast the sequential methods pursued at present, and in particular, offers an alternative to the sequential, non-iterative “waterfall” image of a project.  In IS Education, it is often assumed that teamwork skills are covered in such courses as Business Communications and Organizational Behavior.  It is also assumed that IS students receive sufficient training and practice in teamwork in such core courses as Management and Marketing.  IS professors are also not necessarily well trained or skilled in issues related to teamwork.  Most “learned by doing,” or from practice and experience.  Such learning is useful and very practical, but does take time (a commodity in short supply in IS or any other curriculum).  To quote a common description, these professors learn “by trial and error.”  Errors, however, are expensive in terms of time and serving students less effectively while the “error” occurs. In contrast, future employers of IS students expect students to be able to perform at a high level in many aspects of their job very soon after employment, including a variety of teamwork skills.  Thus, far more specific and more formal preparation of IS students for their roles as future team members is necessary.
Speaking very generally, we could say that teamwork in IS education typically involves:
1. Self-formation of a team based on proximity and affinity, and not on the mix of skills needed to do well on the project;
2. Working as a group on the project, with no (or at best informal) allocation of roles, and no allocation based on the differential skills of the participants; 
3. No control of the amount or quality of work done by team members, leading to a “short tail” effect in which poor students receive inordinately high grades that are actually the result of a few, or even one, team member; and
4. No explicit development of teamwork skills or explicit reinforcement of teamwork skills learned elsewhere.
This method proposed here was developed to overcome these deficiencies.
Because of the many team roles played by IS professionals, the IS curriculum must focus on and develop the skills associated with these roles.  Indeed, the IS professional never knows when she or he be assigned any specific role in teamwork, and must be prepared to perform activities associated with any role.  In this paper, we identify such skills and offer a teamwork educational model to develop them. 
The teamwork model proposed here makes more specific to IS education the work of Bacon (2005), who noted that teamwork is under-researched in business education literature.  Of particular interest is Slavin’s (1988) suggestion that the two conditions essential for successful peer learning, such as teamwork, are positive interdependence or “group goals,” and individual accountability.  Slavin reinforces Bacon by stating further that team learning improves learning outcomes, but only when the group tasks involve both team goals and individual accountability goals.  The teamwork method presented here addresses problems associated with the group grade approach to teamwork.  Instead, it incorporates the findings of Colbeck et al. (2002), who have demonstrated that there are interdependencies in team projects at the college level, of which several are not assessed well (or at all) by a common group grade. 
As suggested above, conventional teamwork in IS education often involves self-selected teams in which teams members choose their own role within the team.  Such a team is counter-productive when viewed against the full range of teamwork skills the IS professional must possess.  The danger of the self-selected team is two-fold: first, self-selected teams do not tend to have members of divergent skills and interests; second, the cohesiveness of self-selected groups is reflected in an undesirable similarity in attitude and performance.   Anecdotally, we note that teams tend to be made of those who sit in close proximity, often because they share previous friendship, and are formed with students with similar academic performance. The result is a team composed of members who share personal affinity and social comfort, often performing at similar academic levels, and which does not include individuals with divergent views and a range of academic achievements.  This, we suggest, is not conducive to learning the many roles and skills one must have to serve successfully on professional IS teams.
Many IS professors are conscious of the problems associated with self-selected team.  They address the problem by selecting teams for students, typically using a randomization process to decide who gets on particular team.  This, however, introduces an additional danger of self-selected teams.  Typically, no assignment of roles within a team is made.  Individuals on the team tend to gravitate to roles in which they are comfortable, which does not include divergent views and with a wide range of academic skills.  All too often women students take on stereotypical roles (Heilman and Haynes, 2005).  Thus, the teamwork experience tends to reinforce skills in which the student in already strong and does not offer him/her the chance to explore new roles or to exercise roles in which s/he is weaker.
The risk of assigning female students to roles based on stereotypes demands our special attention.  The IS professional is dominated by males, and all too often the make-up of the IS student body has a corresponding large proportion of males.  Such gender dominance is unhealthy to the long-term prospects of the profession.  Permitting assignment of roles based on, or influenced by, gender-based stereotypes only reinforces those stereotypes.  At the same time, stereotypical roles tend to deter females from pursuing a career in IS and thus becoming, first, an IS major.  Female and male IS students should be exposed to all aspects of IS teamwork aspects.  The teamwork method presented here is a step toward achieving gender equality in roles within IS student teams (Heilman and Haynes, 2005).
2c. Teamwork in the IS literature
There is also a small body of research in the IS literature relative to teamwork in the IS profession, and IS education in particular.  White (1984), for example, approaches the issue from a Jungian model.  She argues that in many fields, including the IS field, individuals of the “sensing/thinking? cognitive style dominate.  These individuals see problems as structured and frequently seek technical solutions to problems.  She argues that other cognitive styles, such as intuitive/feeling, would be beneficial as these individuals see problems more holistically and place greater emphasis on communication, cohesion, and consensus within the group.  However, when teams are self-selected, members gravitate to others with the same cognitive style, thus reinforcing dichotomies.  The role of the Instructor, it follows, is to ensure a variety of learning, interactive and problem-solving styles, and in particular to include those styles that are not common in the IS field.  The work of Kaiser and Bostrom (1982) further supports this point.  They note that often there is an inherent conflict between users and IS professionals.  Users tend to have a more broad and more organizational view of a problem (similar to the intuitive/feeling paradigm) while IS professionals see the problem within a prescribed logical framework (similar to the sensing/thinking paradigm).  Given this empirical support, it is incumbent on IS professors to develop other styles of learning and interaction, and teamwork is an excellent venue for this part of the student’s education.
3. THE ROLLING CELL MODEL
3a. Development
Having critiqued the use of teamwork as it is often practiced in IS education, we now turn to the development of an alternative teamwork model which addresses the deficiencies discussed above and possesses the advantages listed below.  These advantages are based on the four-team roles identified by Millis and Cottell (1998); details of each will be developed later in this paper.  The relevant points are:
1. the specific roles that compose teamwork are isolated so that students may develop and practice the skills associated with these roles; the IS professor can also assess the student  in each of these specific roles to the degree desired by the Instructor;
2. students rotate through the several roles, developing and exercising skills associated with each and thus developing the student into a more skilled and agile member of teams in his/her future career;
3. simultaneously, students learn that each role’s output is used immediately by the next student in the rotation, developing stronger interdependency between members;
4. because other team members are immediately dependent on the previous team member’s work, there is strong social pressure to deliver quality work; and
5. collectively, the team’s final submission is truly the work of the entire team, with the individual contribution of each member identified and possibly graded under a specific rubric. (Suggested rubrics for each role are offered in the Appendix.)
IS professors face additional complexities in the development of student team projects. Team projects in the IS curriculum have dual objectives: the first objective of team projects is to learn the technology or other subject matter under study; the second objective is learning and developing teamwork skills. The focus of this paper is on the latter.  The fact that IS professors often (quite properly) assess the team process itself as a classroom team learning experience does not model future team participation in a professional capacity, in which often only the results achieved are evaluated.  The focus on process as well as results is a distinguishing characteristic between teamwork in the IS curriculum and in professional practice.  This distinction is desirable as skills in a variety of teamwork roles are expected of the IS professional, and justify the focus on teamwork process within IS education.  We argue that teamwork in the IS curriculum is an appropriate place to learn and reinforce these skills, particularly those of special relevance to the IS profession. Thus, it is important to note that a student beginning his or her professional IS career is presumed to have a solid grounding in both technical and teamwork skills. The alternative teamwork model proposed here can be used to develop the latter set of skills.
The literature on student and professional teams suggests that teamwork is best facilitated when: 
1. an advantageous team size is two is utilized (Bacon, 2005);
2. students learn best in teams when teaching each other;
3. students in teams must work within several types of interdependencies;
4. students are evaluated individually for their teamwork contribution; and
5. professors help students to learn and supervise students in a variety of teamwork skills and behaviors.
An extensive review of the literature concerning team size and its effects on learning outcomes supports these assertions.  Bacon (2005) notes, for example, that “there is strong theoretical and empirical evidence that a group size of two is adequate to achieve the benefits of peer learning, as long as the learning task involves positive interdependence and individual accountability” (p. 252).  Millis and Cottell (1998) have designed roles to help students interact effectively pair-wise, and Hernandez (2003) further refined their findings.  Most insightful of all is Goldschmid’s (1971) finding that the simplest and possibly most effective implementation of teamwork is a method in which two roles fit together in a “jigsaw” manner, which he calls the “learning cell”.  The teamwork method proposed here borrows heavily from the roles developed by Millis and Cottell, as subsequently enhanced by Hernandez, integrated with the Goldschmid’s “learning cell” model.   It begins with the recognition that the pair-wise teamwork of Goldscmid’s model per se is impractical in the IS curriculum.  However, many of its benefits can be achieved by integrating it with roles proposed by Millis and Cottell and implemented here with respect to IS education teamwork.  We have termed the proposed method the Rolling Learning Cell (Goodnight, 2005).
In the Rolling Learning Cell method, a team project is composed of two stages.  The first stage is a development stage in which the team members work through the roles described below, each developing a distinct and important part of the project; each of the several tasks requires a different skill set.  In a prescribed sequence, each team member teaches the subsequent team member about what s/he has learned.  This step implements Goldschmid’s “learning cell” concept and extends it by having the learning cell “roll” through the entire team. Second, after working through the pair-wise structure, a full team stage occurs: the team works as a whole to develop the final project submission.  Both stages are described below.  People generally understand a subject in much more depth after teaching it: this same phenomenon is applied to students as each exercises his or her role and then teaches what s/he has found to the subsequent team member.  This is encapsulated in the well-known saying: “If you would know anything thoroughly, teach it to others” (Tyron Edwards, 1809-1894).
It is our key hypothesis that the quality of the project produced by the team as a whole will be significantly improved when compared with individual student work.  In fact, we argue, the individual work stage leads directly to the improved group output.
3b The First Stage: Pair-Wise Teamwork Stage 
There are four roles developed in the pair-wise team development manner.  The model is designed for team of four but with adaptations can be utilized for teams of three or five, as discussed below.  The roles are Project Coordinator, Research Analyst, Implementer and Writer.  These names were chosen to parallel the roles identified by Millis and Cottell (1998).  We hasten to add that the names of the roles can be altered to suit the needs of a particular project, and the Rolling Learning Cell method itself can be applied flexibly as dictated by the assignment and the Instructor’s preferences.  Each role is described briefly below.
The roles discussed here are specific to an IS project as implemented in the project model discussed here.
3b1. The Project Coordinator. The primarily role of the Project Coordinator is to create a vision for the project.  This is a well-known characteristic of a team leader. S/he is responsible for creating an outline of the project and a time line for its completion. Thus, this role parallels the role of Team Leader in a professional teamwork project. The outline s/he creates contains the sections, heading and subheadings that will organize the final paper.  This structure will be maintained throughout the first stage of the project but may be modified in the second stage of the project, as will be noted in the discussion below.  Information derived from lecture, the text, outside research, and consultation with the Instructor helps to generate the outline.  The project deadline and experience with earlier assignments helps to establish the time line.
The most significant duty comes at the end of the Project Coordinator’s job: s/he must form a “learning cell” (Goldschmid, 1971) with the subsequent team member, the Research Analyst.  Working as a learning cell, the Project Coordinator must teach the Research Analyst everything the Project Coordinator has learned and decided. As suggested above, it is in the act of teaching that the Project Coordinator learns most about his or her role. As will be seen, this learning cell is repeated at the end of every step of the teamwork stage of the project.  This is what gives the proposed method its name: the Rolling Learning Cell (Goodnight, 2005).  A suggested rubric for the appraisal of the Project Coordinator’s role is in the Appendix.
At the Instructor’s option, the work of the Project Coordinator may be reviewed, feedback may be given or the work could be graded.  If this option is chosen, however, the Instructor must be prepared to provide extremely rapid turn-around.  Rapid turn-around would be necessary for all members discussed below as well to allow students time to make effective changes. It is perfectly acceptable for the Instructor not to evaluate the Project Coordinator’s work (or the work of any subsequent role), withholding evaluation until the team has completed its work.
3b2. The Research Analyst. The Research Analyst’s primary role is the specification and scoping of the project.  S/he will develop the detailed specifications of each aspect of the project, within the outline provided by the Project Coordinator.  As the title suggests, this task often requires significant research; the word “Analyst” in the title suggests parallels to the roles of a systems analyst or software designer.  Frequently, s/he must decide the technology to be used in developing a project.  If the use of a particular technology, software or tool is the objective of the project, then the role of the Research Analyst is to determine which aspect or approach suggested by the technology under study is most appropriate to achieve the project’s aims.  The Research Analyst must carefully log each source from which s/he may draws information; these notes will become the basis of the References section of the final team paper.
At the end of this phase, a new learning cell is established.  The Research Analyst teaches the next team member, the Implementer, to make sure that the Implementer fully understands the project to date.  In particular, the Implementer must understand completely the specifications of the project s/her is about to execute.  It is in the act of teaching that the Research Analyst most fully learns his or her role. A suggested rubric for the appraisal of the Research Analyst’s role is in the Appendix.
3b3. The Implementer. The name “Implementer” is used to describe the duties of the person charged with the most technical aspect of the project.  Thus the Implementer does the work most IS students would consider to be “the project”; however, in this students are mistaken due to their limited perception of the full range of roles the IS professional must execute.  Note that implementation does not dominate the process or indicate to students by its place within the structure to have greater importance than other roles.  This permits the IS professor to present the full range of roles associated with a project, and allows the Instructor to place the technical aspects of the project in its proper context.   As the job title suggests, this can certainly include the development of a functional system in the environment specified by the Instructor; more generally, it is the creation of products, such as web pages, network designs and a myriad of other tasks faced by modern IS professionals.  Whatever the task may be, however, the Implementer may not move beyond the specifications given him or her by the Research Analyst.  Such a restriction reflects a common experience for IT professionals, who find they must follow a specification even though they believe they have a superior solution.
At the end of the Implementer’s work, the technical work of the project is done, but the work of the project as a whole is not.  The Implementer must form a new learning cell with the next team member, the Writer, to teach the Writer fully about the system s/he has developed.   Once again, it is in the act of teaching that the Implementer learns the most.  A suggested rubric for the appraisal of the Implementer’s role is in the Appendix.  The key point is that the Writer must deeply understand the system to carry out his or her responsibilities.
3b4. The Writer. As the name implies, it is the Writer’s role to develop a report on the team’s work.  This is done, in part, to address the crucial, but often overlooked, role of documentation in projects, and in particular documentation that records the decision making process in the development of a system.  Of course, in class projects, the system is generally developed as part of the project, but often in professional projects the goal of the team is to focus on identifying needs and functionality; these become specifications which are then submitted to the IS Department.  That so much systems development today takes place in other departments, even in distant countries, emphasizes the need for clear, straightforward and unambiguous specifications.  Thus, the skills learned by the Writer are particularly relevant.
The result of the Writer’s work is a first draft of the team report, which is done in the manner specified by the Instructor.  Most often this includes the development of a retrospective team report, the development of user instructions necessary to use the system (the genesis, in fact, of a subsequent user manual or help system, whether in print or solely in electronic form) and sufficient detail about the system to serve as the basis for technical documentation.  This is an improvement over conventional IS instruction teamwork, in which teams typically defer the “write-up” of a teamwork project until very late in the process and only as a mundane necessity dictated by the Instructor.  It is the “write-up”, however, in which students develop an integrated and more substantial view of the project, and it should not be slighted.
As with previous team members, at the conclusion of his/her work, the Writer forms a learning cell, but unlike previous iterations, this learning cell is not pair-wise.  Instead, the Writer meets with the entire team to teach them his/her work.  In effect, the Writer teaches the three previous members the outcome of the project to which they themselves contributed.  However, it is the act of teaching that most benefits the learning process for the Writer.  As noted above, the Writer’s work forms, in essence, a refined draft of the team’s submission.  A suggested rubric for the appraisal of the Writer’s role is in the Appendix.  This also marks the completion of the first phase of the project.
3b5. Comments. The roles above describe the first of two stages of the teamwork process. By dividing the project’s work into prescribed roles, the Instructor has the opportunity to view and assess the work of each member of the team individually.  More importantly, the Instructor can view the work of each student as a member of the team, distinct from the content material developed by that individual.  The Instructor may elect to grade individual teamwork components; if s/he does, the suggested rubrics attached in the Appendix will be helpful. The degree to which these individual components are assessed or graded is a function of the Instructor’s judgment. The second stage, to be discussed shortly, addresses the team as a whole.
We hasten to note that the Rolling Learning Cell method is not intended to be used once.  In order that students learn and develop each skill set, at least four group assignments are necessary within a term, in such a way as to ensure that each student is exposed to each role at least once.   This avoids a common shortcoming of  teamwork in today’s IS curriculum, in which members gravitate to those tasks with which they feel comfortable, reinforcing existing skills and not developing skills in which they are weak.  It is left to the Instructor’s judgment whether the existing teams will be maintained for future projects or whether the class will be “re-shuffled” into new teams.  However, care must be taken that each student experiences each role at least once during the term.  Since the total number of students involved is only four, the proposed model can be done in most classes (and note the discussion below when the class size is not a multiple of four.)
In our experience, a project of the type discussed here can be executed in about ten calendar days.  Allowing 2½ days for each student’s role gives him or her time to complete individual submissions.  Even more useful, this length of time helps to accommodate busy student schedules.  It also engenders a real-life skill: negotiating with team members with subsequent roles for more time; alternatively, team members with later roles can negotiate with those with earlier roles to complete the early stages more quickly, thus permitting students later in the process more time.  Because the 10-calendar-day period seems to work well, is it not difficult to run this model a minimum of four times a semester, thus ensuring that each student will experience each role at least once, as discussed in the previous paragraph.
Since the Rolling Learning Cell method is built around four roles, one must address situations in which the class size is not evenly divisible by four.  In this case, we have remainder of one, two or three students.  If there are a sufficient number of teams, the easiest solution is to assign the remaining students to other teams, forming teams of five.  In this instance, we recommend splitting the role of Writer into one responsible for creating a rough draft (“the Secretary”) and one responsible for polishing the draft into a version very close to the final report (“the Editor”).  Sometimes, however, it is necessary to form a team of three.  In this instance, we recommend consolidation of the Project Coordinator and Research Analyst roles.  In either case, the Instructor must be willing adjust his or her expectations accordingly.  In both cases, remainder students receive a sufficient amount of the learning the proposed model is intended to convey.  Note that a student in a split or compressed role should have that experience once.
A typical student concern is the team member who does not carry his or her full load, shirks his or her duty, or, worse, fails to deliver his or her portion of the project on time.  First, using the proposed method, the Instructor and other group members have the ability to observe individual contributions with a great deal of discernment and specificity; in short, a student cannot “hide” within a team.  The ability of the professor to isolate individual student contributions typically motivates a student’s participation. Student shortcomings can generally been seen early on, permitting early intervention and correction by the Instructor.  Poor performance or lack of submissions allows the professor to assign an accurate, lower and defensible individual grade to the shirking individual.  Second, such an event would be inhibited by peer pressure (Slavin, 1998; Bacon, 2005) since, presumably, the team desires a good grade on their work.  Third, if the team member remains recalcitrant, his or her work falls, completely or in part, to the subsequent team member.  This significantly increases the subsequent team member’s workload, and would motivate the subsequent team member to have the offending team member “shape up”.  This leads to an alternative solution: a negotiation between the recalcitrant student and the student who follows him or her with the objective of reallocating the work and the reward from the recalcitrant student to the subsequent tam member. If negotiations do not occur or are unsuccessful, the subsequent team member experiences exactly what a corresponding team member in a professional IS team experiences: he or she must undertake a much larger amount of work than was expected by completing the preceding team member’s undone work.  He or she must then perform his or her own responsibilities, and deliver what he or she is required to deliver to the next team member, regardless of the failure of the recalcitrant student.  This undoubtedly already happens with some frequency in the IS educational teamwork as it is currently practiced; the difference is that under the Rolling Learning Cell method proposed here, the Instructor knows it is happening and can take its occurrence into account when grading the work of the recalcitrant team member as well as that of the team member who is so unfairly burdened.
The Rolling Learning Cell method can be used most efficiently when classroom management software is present.  This software will permit the instructor to “track” the progress of a team as it works its way through the processes described here, and in particular can alert the Instructor early when a particular student is falling behind in his or role.
3c. The Second Stage: Group Work
We state again that the role-based Rolling Learning Cell method described above is the first of a two-stage team model.  The second stage is not unlike existing IS education teamwork practice although, we believe, it is more effective.  The Instructor may elect to review, offer feedback and possibly grade the rough draft presented by the Writer.  The team then meets as a whole to finish the project.  The work to date already has a detailed structure (as envisioned by the Project Coordinator).  At this point, the team may modify the Project Coordinator’s structure to a greater or lesser degree.  Thus, even if the Project Coordinator did a poor job and hampered his or her three succeeding team members in the first stage, the team has still benefited since they have some structure, however weak, on which to build; improving on an existing structure is far superior to the flimsy structure (or complete lack thereof) that so often characterizes existing IS education teamwork.  Similarly, the team is free to alter the specifications produced by the Research Analyst, but has a much clearer idea of the ramification of doing so, since they can see the resulting work done by the Implementer. In a similar fashion, they may alter or improve the work of the Implementer without altering the specifications created by the Research Analyst.  Finally, the report as produced by the Writer is typically treated as a near-final draft, but can be improved by the previous three-team members in ways not previously communicated.  Again, the refinement and improvement of an existing draft; which has possibly been reviewed by the Instructor, is likely to result in a better final report than would result from the “from scratch” writing common in existing IS education teamwork. At the very least, the common practice of parceling sections of the team paper to various team members, which makes for a poor report with varying writing capabilities and styles, would be avoided.  Thus, we propose that a far more professional report will be developed as a direct result of the previous individual stage of the project.  In fact, this is a key objective of the Rolling Learning Cell method.
The Instructor receives a final report that is truly the integrated effort of all team members, while at the same team having a firm basis to grade differentially based on a student’s contributions to the team, if the Instructor elects to do so.  Higher education has rarely utilized a “zero sum” grading practice, yet all too often grading for teamwork projects has not teased out individual contributions.  Indeed, all too often the team grade is actually the result of a subset of talented and hard-working students with the remainder of the team “riding their coat tails”.
For the second stage, a common team grade is generally desirable with two caveats: first, that the weight of individual scores versus the team score must be left to the discretion of the Instructor; and second, that the Instructor retains the right to grade students on the final report differentially for good cause. In most cases, however, the team members will share a common grade, which is desirable as it models how the student’s future professional work on teams will be evaluated.   Unlike the monetary rewards common in industry, grades are not a zero-sum process: thus to award one team a higher grade does not lessen the grade of any other team.  The proposed method addresses this and goes a long way to achieving the model proposed by Che and Yoo (2001) in fostering mutual support and cooperation among team members while permitting individual assessment and reward.
The final, revised report becomes the graded team submission.  The Instructor has a strong motivator at this point, particularly for courses late in the student’s career, by emphasizing the results of this project as part of a portfolio of the student’s work.  Since the student performs a new role for each team project, the student has documentary evidence of his or her capabilities across a spectrum of team-related positions and activities, as well as IS project skills.  This last point emphasizes once again that the teamwork method described here is unsuitable for a single team project, since on a single project students see only a portion of the entire process. The Rolling Learning Cell model should be used repetitively, with the Instructor making certain that each student is rotated through the four roles. 
4. REPORT OF PILOT STUDY
To demonstrate and further explore the Rolling Learning Cell method described here, a pilot study was undertaken.  The course was a junior-level Business Information Systems course focusing heavily on the use of advanced spreadsheet models and their interpretation. The course used a variety of modeling techniques and included some development in Visual Basic for Applications.  The section chosen for the pilot study was small (n = 11), which allowed for a good deal of individual attention and support.  Regrettably, the class size was not an even multiple of four, and thus adjustments in team size were necessary for each project.
The pilot study consisted of four-graded group projects, which followed an abbreviated “dry run” project (not graded) intended to familiarize students with the Rolling Cell Model.  During the individual, first phase of each of the projects, each student’s submission was graded using a pre-determined rubric (similar to the rubrics found in Appendix).  Letter grades were assigned; for computation purposes, the grades were converted to numeric values using a standard scale (A = 95, A- = 92, B+ = 88 … D = 65, F = 55). Thus, there were four individual grades recorded for each student for each project (in practice, this was slightly modified due to the class size, as noted above).  In should be noted, however, that individual grading was a result of the Instructor’s choice and is not mandatory.  Other Instructors may feel that feedback is sufficient and still others may choose to not review the documents resulting from an individual student’s role at all.  The choice made would undoubtedly be influenced greatly by class size and the time available for the Instructor to grade intermediate work.
As noted in the discussion of the model, students learn from working on their individual contribution, integrate this feedback received, and incorporate this into the central point of this model: teaching the next team member all that the individual has learned about the project, both from his or her own work and from the feedback received from the Instructor.  The last student, the Writer, had an even broader teaching task, as s/he was required teach the entire team based on the draft paper.  It all cases, it is in the act of teaching that students learn much about their work.  Each student received a letter grade for his/her portion in the first, pair-wise portion of each project.  Recall that each individual grade was for a different role than all other grades.
The teams then produced a final paper, which was submitted and graded against a pre-defined rubric (this rubric incorporated in large part the content teaching objective of each project; thus no suggested rubric is included here).  This constituted the “group grade” and was generally a common grade for all team members (and was so in all cases in this pilot study).  Thus, for each project, each student has a pair of grades: an “individual” grade based on his or her work in the designated role and a “team” grade based on the final team report. 
We have suggested that the Rolling Learning Cell model has several advantages over more traditional methods of group paper method, most notably the introduction of direct individual assessment within the team project and the establishment of specific interdependencies within the team.   However, we must not lose sight of its primary objective: to improve the student’s teamwork capabilities by isolating and exercising specific tasks involved in the group’s work.  This leads to our key research hypothesis for the pilot study: the performance of the team on the group project would be significantly higher than individual performance. In other words, working through the roles of the first stage would not only benefit students in terms of their repertoire of team skills, but would improve their work on the project as a whole.  In short, we propose, the sum (the final group paper) would be greater than the parts (grades received when evaluated in the designated role in each project).
A series of t-tests analyzed these differences for the four graded team projects. The mean of the eleven individual grades from the first stage was compared to the mean of three group grades resulting from the team project produced in the second stage. Recall that the class size was eleven and resulted in three teams. All students participated in all four graded projects. Thus, the Individual Grade Mean represents the average of the eleven individual grades from the first stage for the each of four projects (identified as Project A through Project D).  The Group Project Mean is the average of the three group papers resulting from the second stage for each of the four projects. A mean group project grade was necessary since the Instructor scored the project on several dimensions related to the subject matter under study. The following results were obtained:

Project
Individual Grade Mean (n = 11)
Group Project Grade Mean 
(n = 3)
Significance
A
81.2
88.2
0.050
B
83.3
87.7
0.039
C
71.2
76.0
0.023
D
85.4
92.4
0.000
The findings are clear: students working together at the team-focused second stage, after having worked through the individual roles of the first stage, performed at a higher level in the group work stage of the project. Interestingly, the same relationship held true when students confronted a particularly challenging project (project C).  Thus, the research hypothesis was supported: the mean grade of the group project was in all cases significantly higher than the mean individual grade.  Further, the significance of the difference increased as the pilot study progressed. This, we posit, reflects the increased learning resulting from individual roles, allowing a more profound understanding of team projects.
Note that in each succeeding project, the student performed a different role, and each student performed each role only once.  As a result, the improved team grades are not the result of improved learning in individual roles, since students did not reprise a previous role.  This suggests that the teamwork method proposed here allows deeper and broader understanding of the final project.  These findings are consistent with those suggested by Slavin (1988).
The individual grade reflects that student’s skill in the role assigned (note again that each student performed all four roles by the end of the semester). This means the Instructor has a solid, documented basis on which to assess individual accountability for each student, which addresses a weakness in the conventional use of teams in the IS curriculum, as noted earlier.  In those uncommon cases in which differential grading of the team project is called for, the evidence provided by each individual’s contribution supports and validates the Instructor’s decision to grade differentially.
5. CONCLUSION
Business schools continue to use team projects as a mechanism for enriching a student’s learning experience by simulating “real world” group projects.  Yet, there are a number of practical and operational problems with the conventional team project. The research reported here indicates that the ideal team size is a “learning cell” of two, but determines that that number was impractical.  However, the teamwork model proposed here takes advantage of that finding within a larger teamwork structure. The teamwork model discussed here the Instructor’s ability to enrich the group’s learning experience.  In this respect, the Instructor is acknowledging that the roles on students in the IS curriculum are fundamentally different from those in the IS professional practice: the role of the IS curriculum team is to teach whatever topic is under study and to improve significantly on the several roles a student may plan in a team.  The proposed method, the Rolling Learning Cell, takes advantage of research on this topic; specifically
1. an advantageous group size is two members;
2. assessment should account for both team goals and individual performance; and
3. the mechanisms of assessment should ideally allow a professor to obtain data that can be useful in developing both team and individual grades (Bacon 2005).
Preliminary evidence indicates that use of the Rolling Learning Cell leads to significant improvement in the team’s final project.
REFERENCES
Bacon, Donald R. (2005).  “The Effect of Group Projects on Content-Related Learning.”  Journal of Management Education, 29, (2), 248-267.
Che, Yeon-Koo and Sueng-Weon Yoo, “Optimal Incentives for Teams”, American Economic Review 91:3 (June 2001) 525-541
Colbeck, Carol L, Susan E Campbell and Stefani Bjorklund, “Grouping in the Dark: What College Students Learn from Group Projects”, The Journal of Higher Education 70:1 (January-February 2002) 60-83
Goldschmid, M. L. (1971).  “The Learning Cell: An Instructional Innovation.”  Learning and Development, 2, 1-6.
Goodnight, Janelle E (2005), “Group Projects:  A Method to Integrate Learning Goals and Desired Grading Components in a Marketing Principles Course,” Marketing:  From Fantasy to the Future, Jerry W. Wilson, ed., Atlantic Marketing Association, Madison, WI, 21, 250-255.
Heilman, Madeline, and Michelle C Haynes, “No Credit Where Credit Is Due: Attributional Rationalizations of Women’s Success in Male-Female Teams”, Journal of Applied Psychology 90:5 (2005), 905-916
Hernandez, S. A. (2002).  “Team Learning in a Marketing Principles Course: Cooperative Structures that Facilitate Active Learning and Higher Level Thinking.”  Journal of Marketing Education, 24, 73-85
Kaiser, Kate M, and Robert P Bostrom, “Personality Characteristics of MIS Project Teams: An Empirical Study and Action-Research Design MIS Quarterly 6:4 (December 1982): 43-60
Meyerson, D., Weick, K. E., and Kramer, R. M. (1996).  “Swift trust and Temporary Groups,” in R. E. Kramer & T. R. Tyler (Eds.), Trust in organizations: Frontiers of theory and research (pp. 166-195), Thousand Oaks, CA: Sage.
Millis, B. J., and P. G. Cottell (1998).  “Cooperative Learning for Higher Education Faculty.”  Phoenix, AZ: Oryx.
Slavin, R. E. (1988).  “Cooperative Learning and Student Achievement.”  Educational Leadership, 46, 31-33.
White, Kathy Brittain, “MIS Project Teams: An Investigation of Cognitive Style Implications MIS Quarterly 8:2 (June 1984) 95-101
APPENDIX
SUGGESTED RUBRIC FOR EVALUATION OF PROJECT COORDINATOR ROLE
1. Structure (proper use of headings, organization, and the like).
2. Use of course text, lecture content and other sources to explain proper use of terms and concepts.
3. A demonstrable understanding of the key concepts to be covered by the project and, where relevant, the proper sequence of activities.
4. The degree to which the time line provided is realistic and executable. 
5. The overall clarity and specificity provided by the Project Coordinator.
6. The degree to which the Project Coordinator’s work is understandable to subsequent students on the project.
7. The feasibility of the project as projected by the Project Coordinator
8. The degree to which the expected response of the team, as outlined by the Project Coordinator, addresses the posted assignment.
SUGGESTED RUBRIC FOR EVALUATION OF RESEARCH ANALYST ROLE
1. The effectiveness and the completeness of a summarizing user data needs, possibly resulting from interviews with the end users.
2. A clear delineation of work to be done further on in the project.
3. The logical placement of summarized information, tables and other information within the Project Coordinator document.
4. The degree to which the technical specifications in the document provide adequate direction to the subsequent student.
5. The use of a correct format in the reference section (e.g., APA or MLA format), number of sources, overall credibility of sources.
6. An analysis of the depth, accuracy and content of information provided by him/her.
SUGGESTED RUBRIC FOR EVALUATION OF IMPLEMENTER ROLE
1. The degree to which he or she executed the specifications provided by the Research Analyst.
2. The quality of the technical work executed by the Programmer.
3. The originality or effectiveness of the Programmer’s approach within the specification given by the Research Analyst.
4. If required, the degree of documentation associated with the technical work. 
5. The verified fact that the Programmer has not modified the work submitted by the Project Coordinator and Research Analyst.
SUGGESTED RUBRIC FOR EVALUATION OF WRITER ROLE
1. Demonstrating a clear understanding of the project.
2. Following the outline originated by the Project Coordinator.
3. Including the issues posed by the Research Coordinator, together with any external research performed by him or her.
4. Including the resolution of the issues posed by the Programmer and general solutions reached, although the source code and other technical material can be relegated to an appendix.
5. Including conclusions, recommendations, implications, and findings generated by the Writer, including any issues proposed for future research. and
6. The report must also be judged as a written document.  Specific items to be evaluated are:
a. The absence of spelling, grammatical, and stylistic errors.
b. The correct use of technical terminology.
c. Logical consistency and flow. 
d. The absence of significant portion of errors in the report. 
e. The professional tone, manner and presentation of the report.
18