Team-Teaching Electronic Commerce: Lessons Learned Mark P. Sena 1 Information Systems Department, Xavier University Cincinnati, OH 45208-5161 C. Edward Heath 2 Marketing Department, Xavier University Cincinnati, OH 45208-3214 Abstract In 2001, two 2nd year faculty members were chosen to team-teach an undergraduate, cross-functional E-Commerce course. Three sections of the course were taught over a two-semester period by the authors of this paper. This article discusses the lessons learned from this experience in regards to both general team-teaching issues and E-Commerce instruction. Keywords: Team teaching, electronic commerce, course development, interdisciplinary education 1. INTRODUCTION Many universities have offered team-taught courses to provide students with specialized, yet integrated instruction on a particular topic. Electronic Commerce (EC) is a subject that, by its nature, involves multiple business disciplines. While a number of universities have developed majors in EC, most programs have looked for ways to incorporate EC into their existing curriculum. However, how do business schools work EC into an already crowded curriculum? David Overby of the Keller Graduate School of Management notes, "Employers are looking for people who have a good understanding of how the Internet works and the ability to comprehend the entire system of e-business... this means that business students need more than programming skills or marketing expertise and must be able to analyze an entire e-business system" (Hromadka, 2000). One solution is to offer a course taught by faculty with expertise in different areas of EC in hopes of providing students with an integrated view of EC. This paper describes the experiences of two instructors (one from Marketing, the other from Information Systems) who taught three course sections of EC together over the past year. In relaying these experiences, we detail the background that led to the course offering, the choices made during course development, and the lessons learned during the past year. These lessons offer insights to those who may be involved in team teaching or instruction of an EC course. This article builds on a paper (Heath and Sena, 2001) composed while the course was being designed that detailed the difficulties in developing team taught EC courses. Course Background The EC course described in this study was funded by a grant from the General Electric Corporation to foster multidisciplinary education. During a two-year period, the grant will fund two faculty teams (one per year) to design and teach multidisciplinary courses. The goal for the program is to have these courses serve as models for future teaching collaborations across disciplines within the College of Business. In spring of 2001, the grant recipients (who happened to be the department chairs of marketing and information systems) offered this study's authors the opportunity to design and teach this new EC course. After attending a conference and investigating different options for the course design, we spent the summer of 2001 in collaborative development of the course. In fall of 2001, two sections of the course were offered followed by one section in spring 2002. The original course design was to be modeled after a course offered by George Washington University (GWU) in 1998. The course, which was described in articles published in the New York Times (April 17, 1998) and Communications of the ACM (Dhamija et al. (1999), involved students in creating a functioning online market system. In this course, the students developed web-based business along with an infrastructure that enabled them to buy and sell goods and services electronically, promote and market their businesses, accept payment and track their relative position among the class groups. The course split students into six groups, each with a computer scientist. The groups spent the first few weeks of the semester developing their web-based businesses then spent the next several weeks developing the payment systems and market infrastructure. The course's final four + weeks involved the actual buying and selling of goods and services. In evaluating the GWU course design, we saw several obstacles to implementing the same course model. The instructors of the GWU course were able to select their roster of students from a pool of applicants that included (presumably) a very bright group of graduate and undergraduate students with a wide range of skills to contribute. Dhamija et al. also mention that they received a great deal of technical support from area businesses. Our course was open to all undergraduate students with no prerequisite course requirements. In general, the course attracted a mix of students majoring in marketing, information systems, and various other majors. However, very few students entered the course with extensive technical skills. While we were fortunate to have some funding from the grant, we did not have extensive technical support either within the university or from area businesses. In addition, the GWU course was taught during the peak of the EC boom when there was tremendous excitement about the topic. Many businesses in this era started ventures quickly and raised a great deal of capital. Today, after the demise of many these startups, venture capitalists (VCs) take more time with their decision and require greater diligence in planning. In a recent Newsweek article (Levy, 2002) VC Jim Breyer notes "We're still doing deals, but now they're well thought through...two years ago we would have done it in a week." Another VC, Greg Galanos, states that today he "won't consider companies without viable business plans, working prototypes, and a sense of commitment." That sentiment is representative of the strategic based thinking that guided our development of the course. We decided to focus on importance of "development and strategies" which eventually became part of the course title. Course Overview Our course structure included a major group project that required both the development of a detailed business plan and a prototype web site. The project accounted for half of the students' course grade while student performance on quizzes, assignments related to various EC topics, and class participation determined the other half. The course project was broken down into three major parts: 1) a strategic plan that included a business description, market analysis, preliminary financial plan, and project plan; 2) a technical design document that included a preliminary web design, hosting and security plan, payment and data collection options, and an updated project plan; and 3) a completed business plan and prototype web site that included a working web site, detailed advertising and promotional plans, operations management and delivery systems, customer service protocols, and future goals and plans of the business. The project teams were determined at the start of the semester by the instructors based on surveys related to student interests and technical experience. Course time was divided between lectures, discussions, group meetings, and even a movie (Startup.com, 2001). The content of the lectures and class discussion included an introduction to the Internet its history and functionality, discussions about various EC Products and Markets, and an overview of Marketing Strategy, Business and Financial Planning, Advertising and Promotion, and Project Management as they pertain to EC. In addition, we introduced discussions about E-Payment Systems, Web Design Fundamentals, and Hosting and Security Options. A brief introduction to building a Yahoo store was replaced by a FrontPage tutorial in the Spring semester. Finally, we conducted discussions about EC Ethical Issues, EC Failures and the coming rebound, and Amazon.com using a case study. The course was taught in a computer classroom and occasionally involved hands-on activities. Both instructors attended nearly every class meeting, however, lectures were generally led by one of us. During the first semester, the course included two sections. According to the course evaluations, the course was met with mixed reviews from the students. While most students really seemed to enjoy the course, a number of students expressed displeasure. Much of that displeasure stemmed from problems within particular project groups. However, some students believed that they were not given adequate direction or support on the project. In developing the project assignment during the first term, we did not anticipate the role ambiguity that developed within many of the groups. To correct that problem for the second semester, we assigned students "organizational" roles in their project groups. We also struggled with the level of detail to provide students regarding the expectations or content that should be included in each section of the business plan. We did not want to provide students with a "template" business plan that resulted in similar, narrowly focused replicas of our examples. While some groups developed remarkable projects during that term, others had lackluster results and blamed us for a part of their failure. During the second term, we made some minor but important changes to the project and course structure which seemed to improve student perceptions significantly. First, project team members were assigned particular "organizational" roles including a CEO responsible for coordinating each deliverable aspect of the project, a CIO responsible for conceptualization and development of the information technology requirements, a CMO responsible for investigation and development of the marketing strategy and a CFO/COO responsible for the development of the mechanisms to ensure order fulfillment (delivery, logistics), post sale support (customer service), and determination of the financial requirements. Students also better understood the expectations regarding each project phase. Finally, we had a better understanding of the problems that groups were likely to encounter and better coordinated the presentation of content that students would need prior to each section. After the second term, a self-administered survey revealed that 23 of 25 students expressed satisfaction with the course (to date, formal evaluations have not been returned). Background on Instructors The instructors of the course were C. Edward (Chip) Heath, a Marketing faculty member and Mark Sena, an Information Systems faculty member, both in their second year as assistant professors. Like all paired colleagues involved in team-teaching a course, the two of us have many similarities and differences. Our similarities began when we both attended the same university for our doctoral studies only one year apart. In addition, we are just four years apart in age and share many similar interests regarding both sports and entertainment. We also share an informal, relaxed style of instruction. Although we share these and other similarities, we do have minor differences. Our fields of marketing and information systems have inherent differences in approach: information systems faculty tend to focus on function while marketing faculty tend to emphasize form. This was evident in both our presentation materials (Chip's being more graphic, Mark's more text based) and presentation styles (Chip's filled with bad jokes; Mark's being more straightforward). In addition, though we both attended the same university, we were in different programs and knew one another only slightly prior to beginning our collaboration. Finally, while Mark had more extensive business experience prior to teaching the course, Chip was the more experienced EC instructor, having taught Internet Marketing numerous times. As a result, we began our team-teaching assignment on a very even playing field in terms of power. 2. LESSONS LEARNED: TEAM TEACHING In our previous study (Heath and Sena, 2001), we reviewed literature dealing with team teaching issues. This study re-examines those twelve considerations regarding team taught experiences (George and Davis-Wiley, 2000) detailing our experiences relative to each of these points. 1. Agreeing on expectations and teaching plans With many teaching partners, this could be a major stumbling block to course development. Initially, we found out that we had somewhat different styles planning a course. Chip tends to plan each course session during the term while Mark prefers to make broad semester long plans and give the students details as the semester progresses. However, we had little difficulty in comprising a plan that satisfied both styles. Prior to the each term, we agreed on a broad plan for expectations and teaching plans that we provided to the students in their syllabus, and developed a detailed adaptable plan for our use. 2. Taking extra time for planning and evaluation This will be a challenge for any teaching collaboration. Each step of the planning and grading process involved additional time and collaborative effort. Many times, we met at the very last minute to iron out details prior to the class session. Grading also caused us minor aggravations from time to time. While one instructor often graded assignments with small point values, exams and project documents required both of us to be included. Although we are both adept at communications technologies, coordination is still difficult and additional time is needed. 3. Determining appropriateness of lecture interruptions Both of us maintain very informal environments and encouraged feedback and interruptions. For faculty with very different teaching styles, this could become a thorny and difficult problem. One of the best aspects of having another instructor in the classroom is the ability to get their input and insights into the current discussion topic. Class discussions, in particular, were aided by the presence of two faculty (although, when we had two course sections, it felt a little awkward having the identical "spontaneous" discussion a second time during the day). 4. Making evaluation criteria clear to students We had little trouble agreeing on the breakdown of exam, assignment, and project point values. However, in teaching the class for a first time, it was difficult to convey our performance expectations related to each assignment. In particular, during the first semester, the students seemed to underestimate the rigor of work that we expected regarding the evaluation of the project. 5. Assuring that all deadlines, assessment and other issues are consistent. It was actually remarkable how consistent we were in these matters. During the first semester, we agreed to change a few assignment due dates but there was little disagreement between us. Regarding assessment, we were very much in line with one another (often within one percentage point) in evaluating student performance. Well developed expectations and discussions about grading during the course development stage could help detour problems during the actual semester. 6. Leaving egos at the door Luckily, we were able to conduct the class without letting personality issues interfere. In other collaborations, this could be a paralyzing and difficult issue. 7. Being prepared for the amount of work involved; Overall, we found that the amount of work involved was not overwhelming. In many ways, the extra time required to coordinate, grade, and plan was offset by the shared lecture requirements. We were fortunate that our departments consider the team-taught course to be part of a full teaching load. Otherwise, the amount of work (if only half of the teaching load was credited) would be prohibitive . 8. Being flexible and willing to learn from colleagues One of the most valuable lessons from a team taught experience is to learn not only the content from your colleague but also the teaching and course administration approaches. We both learned new ways to do things that we can adapt to our own courses. 9. Being humble and willing to accept fault Though no incident occurred leading either of us to accept responsibility, we did learn from our short-comings during the first semester, accepted it as OUR problem to solve, and worked together to develop solutions. Joint planning can help reduce the likelihood that this becomes an issue. If the team planned the course, there is no individual ego, blame, or fault at issue. 10. Working out differences in private rather than in the classroom While we did not have many serious differences, we began the first semester by making a series of comedic put-downs towards one another. While most students seemed to enjoy the exchanges, they may have set a negative tone for others. In the second semester, we continued to exchange the occasional barb, but they seemed to be taken lightly by all. More importantly, the students saw us as a strong committed team striving toward the same goal. 11. Accepting the partner as an equal For our collaboration, we were equals in almost every regard. The collaboration would likely have been more difficult if we had not both been 2nd year faculty members with no particular status advantage. Besides making the course more difficult to run, students are able to sense the tensions between faculty and either take advantage of it or have difficulties learning in that environment. 12. Enjoying the experience to learn and grow from it. For us, the experience was very enjoyable and rewarding. While most articles on team teaching report similar, positive experiences, we recognize that such literature could suffer from non-response bias as negative experiences are undoubtedly less likely to be submitted or published. 3. LESSONS LEARNED: ELECTRONIC COMMERCE INSTRUCTION Regardless of whether our course had been taught by one instructor or two, teaching EC to a multidisciplinary group presents a number of issues. These issues include: the level of technical instruction, the type of EC tools to employ, the level of cross-functional learning expectations, and issues related to administration and support. Technical vs. Business Focus We determined that our course would focus more on the management of technology and the learning of technical concepts than on learning the hands-on skills required to build commercial e-businesses. One reason for this focus was the multidisciplinary nature of the course. The course was offered as a cross-listed elective for marketing and information systems majors and others who had an interest in the topic. Few students had extensive hands-on skills and there was great variance regarding the technical expertise of the students. Another reason for this focus was the role of the course in the college curriculum as our college offers courses in both Web Fundamentals and Advanced Web Development. Thus, we sought to minimize the overlap between our course and those existing courses. We made it clear on the first day of class that the purpose of the course was not to focus on web page creation but the business aspects of EC. EC Tools Although the course did not focus on web development techniques, we required a working prototype to satisfy to course project. Therefore, we had to offer students instruction and resources to develop their online businesses. There are a number of different alternatives that faculty can choose for such tools ranging from "template: web hosts (e.g., Yahoo Stores), hosted web sites with greater support for customization (e.g., BigStep.com), to software packages that varying levels of complexity and support for EC features such as shopping carts, catalogs, and transaction processing mechanisms. In each case, there are trade-offs in level of customization, complexity in learning, network support requirements, and costs. In the first semester, we purchased a software package called EC Builder, which required little expertise but allowed the students to create a fully functional, but limited, online store. During the first semester, we demonstrated the software to the class and had them open temporary Yahoo Stores to get some hands-on exposure to EC features. During that first term, several groups struggled with their web sites, most of who chose to simulate the EC functionality using traditional web development tools such as Netscape Composer or Microsoft FrontPage instead of adopting EC builder. During the second term, with a member of each group assigned as CIO, there was greater accountability to emphasize the web portion of the project. In addition, we spent a lesson teaching all students how to use FrontPage so that everyone could contribute, to some degree, to the web development activities and held a special CIO session conducted by Mark to introduce the groups to EC builder. Cross-Functional Learning Expectations The primary goal of a cross-functional course is for the students, regardless of their major, to learn each aspect of the topic with an equal amount of proficiency. The difficulty is taking the students out of their comfort zone and exposing them to the viewpoint of the other functional area. The first thing we did was to require all students to learn each aspect of EC for the purpose of assignments and quizzes. The marketing students had to answer questions focused on IT project planning and the IS students had to discuss the importance of branding. We had mixed feelings about assigning project roles (CIO, CMO, etc.,) to the students because we felt strongly that each student should learn about every aspect of the EC system. However, we learned from the first semester that the student groups divided the project tasks into sections rather than collaborating on each anyway. Short of having each student develop an independent project, there is no easy solution. We felt, overall, that students learned as much as they feasibly could about the overall EC systems, while promoting a greater understanding about the role their field plays in that system. Course Administration In terms of curriculum, a new course in EC must be positioned to complement but not overlap existing courses. This issue can also change over time as content once considered exclusive to EC may become mainstream to the discipline within the next few years and force the departments to consider what separates EC from their traditional material. These issues will confront the other disciplines as EC becomes integrated into overall business strategies. This not only causes the EC course to change but more importantly changes its relevance within he curriculum. Another major administrative issue in EC instruction is computer resources and the reliance on university computing support. Although most universities have high-speed Internet access and an in-house web development team that supports university web resources, there are often difficulties in supporting EC. Dhamija et al. noted such problems as system crashes, problems with policies for interfacing with university staff, lack of access to critical resources (e.g., common gateway interface for web server), limited web resources, and computer distractions. We faced many of these same issues in our course. A major reason for choosing EC Builder as a development tool was the ability for student web sites to be stored on disks or file servers rather than on university web servers and for its ability to function without requiring server scripts or any other type of university support. 4. LESSONS NOT LEARNED: LIMITATIONS OF THE COURSE As we noted in the rationale for the multidisciplinary, team-taught course, EC involves all aspects of business, which, of course, are not limited to marketing and information systems. Thus, vital aspects of EC were not given much if any attention in our lectures, class discussion, and group projects. For example, the importance of understanding the financial aspects of an EC start-up venture is critical to business success. Because of the abundance of topics relating to the IS and marketing areas, lack of expertise of the instructors, and already complex nature of the group project EC financial issues were covered in only one lecture. The same situation applies to the operational aspects of an EC venture. Most of the group projects were very strong discussing the technical details of the web site and/or the marketing and promotional aspects, but failed to consider how their products and services would be procured and delivered, nor did they fully consider the financial or accounting requirements of their venture. While we covered a great deal of material, we were left with the notion that much of the learning was "a mile wide but an inch deep". That is, they have a surface knowledge of various EC issues but do not have detailed knowledge of any particular aspect. This is a feeling that most professors have about their regular coursework and is especially salient for EC courses. 5. CONCLUSION How was your teaching experience you ask us. "It was great." Would we do it again you query. "We'd love to do it again." However, due to administrative issues the likelihood of that happening again is not very high. So, like a couple of outcasts from a failed dot com venture we walk away from this experience having learned a great deal about the industry and even more about ourselves. We feel that what we did was right, that we did it the right way, and that we put everything we could into its success. Because of this opportunity, 66 students had a unique chance to learn about one of the most exciting and revolutionary business topics the world has ever known. After all, isn't that why we do what we do? REFERENCES Dhamija, Rachna, Heller, Rachelle, and Hoffman, Lance J., 1999, "Teaching E-Commerce to a Mulit-Disciplinary Class." Communications of the ACM, September, 1998, pp. 50-55. George, Marshall A. and Patricia Davis-Wiley, 2000, "Team Teaching a Graduate Course." College Teaching, Spring 2000. Heath, C. Edward and Mark Sena, 2001, The Challenges of Team Teaching E-Commerce", Proceedings of 2001 ISECON Conference, Cincinnati, Ohio. Hromadka, Erik, 2000, "E-Curriculum?" Indiana Business Magazine, Feb. 2000, p.55. Levy, Steven, 2002, "Silicon Valley Reboots: The dot-com bust was bad for Wall Street, but it was the best thing to happen to this high-tech crucible." Newsweek. March 25, 2002. p. 42. Startup.com, 2001. 1 sena@xu.edu 2 heathc@xu.edu