A Systems Analysis and Design Semester Project: A Stand-alone Project vs. a Competitive Project Ranida Harris rbharris@ius.edu School of Business Indiana University Southeast New Albany, IN 47150, USA Abstract Numerous educators have suggested and shown the value in having a real world project for a Systems Analysis and Design course. These real projects are often structured as semester group projects. Traditionally I have had each group work on a different client system. I changed this project structure when an opportunity presented itself to have students complete projects on the same client in more of a competitive environment, similar to an organization soliciting bids on analyzing and designing a new system. At the end of the semester, based on both student comments and the final deliverables, I concluded that there are definite pros and cons of having stand-alone vs. a competitive semester project. However, if I had to choose one, I would have students complete competitive semester projects as experience led me to believe that overall outcomes are better and more positive. Keywords: group project, Systems Analysis and Design, teaching methods, semester project 1. INTRODUCTION Throughout the years there have been a number of different approaches to teaching a class on systems analysis and design (SAD). As opposed to some of the other computer courses (e.g., programming or hardware), a number of aspects of the SAD course are less clear and harder to illustrate and practice in a pure lecture environment (Griffeths & Oates, 2003). As a result, a number of instructors and studies have argued that the traditional lecture approach is not optimal (e.g., Felder, 1992; Griffeths, 1998; Hackney, McMaster, et al., 2003; Helwig, 2006). To improve student learning of the SAD material, instructors often use projects. These projects range from individual to group projects (Lenox & Woratschek, 2005), and vary from fictional situations to actual cases to current real world projects that are drawn from companies (e.g., Cappel, 2002; Scott, 2006; Surendran, Ehie, & Somarajan, 2005; van Vliet & Pietron, 2006). In my classes, I have always used semester long group projects drawn from real companies. These projects have provided students with the opportunity to apply the material in the book and that learned in class (Marakas, 2006), as well as have the exercise of analyzing and designing a system for a client (e.g., Connolly & Begg, 2006; Misic & Russo, 1999; Noll & Wilkens, 2002). However, at the beginning of the fall of 2004, I was approached by a colleague about a potential class project, an information system for a journal to be used in the submission and review process. After learning about the system background and user needs, I decided that this situation could serve as an excellent learning experience for students in the SAD class. Additionally, to ensure that the final product (the deliverable) was as strong as possible and to motivate student groups, I made the decision that all groups would work on the same semester long project. As it turned out, structuring the class with a competitive group project provided for a unique learning experience with certain advantages and disadvantages when compared to the stand-alone group project. In the sections that follow, I will describe the general content of the SAD course. This will be followed by a discussion of my normal approach to a semester (stand-alone) real world project and the situation that allowed for the competitive real world project. Finally, I will summarize findings related to the differences between the stand-alone and competitive SAD semester projects. 2. CONTENTS OF THE SYSTEM ANALYSIS AND DESIGN COURSE Information Systems Analysis and Design is a required course for upper-level students in my university. The course objectives for this course include: 1. Understand and use the systems development life cycle. 2. Analyze an existing information system. 3. Generate alternative solutions to an information systems problem and make recommendations regarding the new system. 4. Understand and explain the systems design, implementation, and maintenance processes. 5. Work successfully as a group on a common problem. Student grades for this course are determined based on quizzes, exams, homework, participation, and a semester-long team project (where 20% of the project grade is based on peer evaluations). This team project is one of the highlights of the class, as it provides the students with a real-world opportunity to work on a system and comprises 30% of the overall grade for the class. 3. TRADITIONAL APPROACH TO A SEMESTER REAL WORLD PROJECT At the universities where I have taught, including my current position, I have taught the SAD class using a semester long project. This project is completed by a group, ranging from 3-5 students depending on the class size. The projects are drawn from organizations where the students currently work or have worked in the past. If current or former employers do not provide an appropriate setting for the work project, students are told that they can complete a project on a company where they know an employee(s) at the decision-making level. In this case, the students would have to interview the employee to determine the problem, system needs, and the other necessary information. In completing this semester long project, all groups work on different systems in different organizations. At the beginning of the semester, students are grouped into teams. During the first few weeks of the semester, students work on the initial discussions about what they want to do, select the organization, and define the information system for the project. The project identification is a very crucial step as it will have a significant impact on the final project outcome. On the one hand, projects with too large a scope, processes that are too complicated, or sources of information that may be unclear, might result in roadblocks during the semester and leave students feeling discouraged. On the other hand, projects that are too small or consist of only a few simple processes might result in students losing interest and making them feel unmotivated. To help students choose the “right” project, I facilitate the process by informally asking about their ideas and give immediate feedback where possible. In some cases, I ask students to give me a rough draft of the project’s first milestone (described in the next section) and make suggestions, as well as help them modify it as necessary. Most teams have no problem coming up with the system for their projects. Due to students’ diverse backgrounds, especially at my university where most students work at least part time, I have seen many different types of projects ranging from a small individually-owned company to a large national not-for-profit organization. Regardless of the nature of the project, the most important requirement is students must have access to the information about the system. Potentials include a system that a student has used in the past, has access to, or knows someone who they can ask for information when they have questions about the system. Most projects conclude at the end of the semester. In some cases, however, students continue working on the projects as a part of their work assignments or personal development. In cases such as these, I would let the student ask for permission from his or her team before continuing with the project outside the classroom. 4. THE SITUATION THAT ALLOWED FOR A COMPETITIVE REAL WORLD PROJECT During the fall of 2004, an interesting situation presented itself. I was approached by one of the co-editors of the university-affiliated journal (The Journal). The co-editor told me that The Journal had been around since 2000, but that the system used to manage the submission, review, decision, and publication process had not been updated in a while. At this point I asked the co-editor a number of questions to determine if this was a problem that could be addressed in my SAD class. After this discussion, I made the conclusion that analyzing and designing a system for The Journal would be an ideal semester project for the systems analysis and design class. I also decided that since the goal was to arrive at the best possible system for The Journal, all groups in the SAD class would work on this project. Thus, there would be a number of deliverables, from which the co-editors and I could choose the best one for The Journal’s purposes. Additionally, by having all groups work on the same project with the same information, the teams would in effect be in competition with each other. The project was organized into multiple segments or “milestones.” Students received an instruction sheet specifying the requirements and due dates for each milestone. There were five milestones associated with this project: 1. Identification of the organization and the information system 2. Analysis of the current system and requirements analysis 3. New systems description and Baseline Project Plan 4. Group presentations and prototype demonstration 5. Prototype and final report The primary purpose of the first milestone was to ensure that students understood the context of the organization and the information system with which they were dealing. To get started, each project group received a copy of the previous issue of The Journal which included the information about the journal, editorial board, review board, and the annual meeting of the Academy of Business Disciplines. Students were also encouraged to setup an initial interview with the graduate assistant who works for The Journal for any further information regarding the organization and the information system (i.e., paper reviewing process). Additionally, students also had the opportunity to observe the graduate assistant as she performed her job. The deliverables for this milestone included a description of the organization, information system description, and the problem statement specifying the needs for the new/improved system. After receiving feedback from me on the first milestone, students started working on the second milestone. The purpose of this milestone was to identify and analyze the current information system in the organization, as well as to describe the new conceptual system (ER Diagram) that will address the problem and fulfill the system requirements. The deliverables for this milestone included a stakeholder analysis, current system characteristics (i.e., system purposes, scope, components, etc.), current system Data Flow Diagrams, new system criteria, and an entity-relationship diagram of the new system. In addition to the information received from the graduate assistant, a Joint Application Development (JAD) session was conducted in the classroom, with tables and chairs set up to resemble a meeting room. Both co-editors of The Journal and the graduate assistant were invited to the “meeting” with the “system analysts.” Students came to class on that day with a list of questions they would like to ask the “manager” and the “users.” During the JAD session, students sat with their team, and each team took turns asking questions. The instructor acted as a facilitator. The purpose of the third milestone was to recommend a new system solution and to complete the Baseline Project Plan. Based on the previous milestones, each project team researched several possible design strategies, selected one design solution that would best solve the business problem at hand, and made recommendations how to proceed with the new system. Deliverables for this process would then be used to guide the project throughout the project life cycle. The fourth milestone involved group presentation and prototype demonstrations. Each presentation was made to the co-editors of The Journal and the graduate assistant. Unlike real project bidding, however, all “competing” project teams were presented in the same room as audiences. After the presentation, I met with the “users” and asked for their feedback on the projects. They were very impressed with the student presentations and were amazed by how much students had accomplished given the limited time, resources, and information. The prototype systems, although designed to perform the same functions, were very different, and each exhibited its own strengths and weaknesses. For example, one group designed the system menu that was simple and easy to understand, yet covered all the system functionalities. On the other hand, another group proposed several creative and meaningful report layouts that reflected the users’ needs. Based on the feedback from the journal editors, the “ultimate” system was a combination of the superior design features from each group (e.g., using the menu design from one and the report design from another). This feedback was then passed along to the students. I made the point to tell them that this probably is how it works in the real world. No single system is perfect. As a part of the last milestone, each group was required to turn in the project prototype and the final report. The final report consisted of all the work from the previous milestones organized in the recommended format for the Baseline Project Plan. The prototype had to contain all proposed forms and reports for the new system as described in the new system description. The final report also included a user manual that described how to start up and use the prototype system. After assigning the project grades, I received permission from the groups to modify the prototype systems they turned in for The Journal. Using their prototypes as the starting points, I spent one weekend during the break modifying their systems and was able to give it to the journal. It took approximately five months overall from the time class started the project until The Journal received a high-quality database system. 5. SUMMARY ABOUT FINDINGS COMPARING STAND-ALONE VS. COMPETITIVE PROJECTS After having completed the semester where there was the competitive real world project to design a system for The Journal, I reflected on the process and outcomes, both in the forms of actual output (the group deliverable) and student comments. My comparison was between the stand-alone and competitive projects, and these differences are provided in Appendix A. The first difference was in the actual student learning. My conclusion was that students learned in both types of projects, but that the learning was different. In the stand-alone projects, students learned a great deal about their own client’s system and in the process applied the material discussed in the SAD class. Additionally, students were unable to rely on what the instructor or other students knew about the system, thus they had to become the absolute experts. However, when there were competitive projects, students also learned the material, but just learned it in a different way. When all students were completing the same project, students again applied the class material and were able to learn from groups that approached issues differently and/or completed work/structured the system in a different and often better fashion. For example, some groups had a better overall design whereas others had superior functionality including reporting capabilities. In this way, students could see how others dealt with the same system, but chose to design it in a different way. Additionally, students learned that there are multiple solutions to any problem and that no system is perfect, with the best systems often taking ideas from multiple places. A second difference involved the actual interviewing of the client. When semester projects are completed independently as stand-alones, groups conduct each of the interviews by themselves. Conversely, in the case of the competitive projects, the interview with the client took place in the classroom. By having all students at the same interview, they are able to use the information gained from other group’s questions, often ones they would not have thought of asking. Additionally, students get to listen to and observe both how and what questions other students ask. In this process, students learn from each other, as the client is the same, but students get to see questions other groups would ask. After the interview session, I asked students about the most challenging part of this exercise. Many of them said that, although they had prepared a set of questions to ask and the order to ask those questions, they had to modify what they had in the real time basis. Because of the unique setting where all the groups were at the interview, many questions were redundant. Students had to change the order of the questions or change the question itself, as the other groups were asking what they have planned. Similarly, they had to change questions based purely on the client answers which may have been unanticipated. Both of these challenges forced students to think “on their feet” and demonstrated the difficulty in engaging in a quality client interview, where one attains all the information needed, but does not waste valued client time. Overall, I thought for the project component of interviewing the client, the reasons discussed made the competitive group project a better learning experience. A third difference is the exposure to other client systems. When the SAD class is structured to have a competitive project, students gain an in depth knowledge of one organization’s system. However, when the class is structured with stand-alone group projects, each group learns a great deal about their client’s system and also learns a little bit about other clients’ systems, primarily through group project peer assessments and end-of-the-semester presentations. In this respect, students are exposed to more systems when semester projects are stand-alone. A fourth difference is the ability to build off of each other. In the stand-alone group projects, students are able to use/build off of classmates thought processes and potentially integrate things other groups are doing by using them in their own client system’s projects (Janicki, Kline, Gowan, & Konopaske, 2004). On the flipside, in competitive semester group projects, students are able to ask others in class for project help (as they have the same client and system). They are also able to be in the same client interview, see what other groups are doing when project milestones are discussed, and use all of this information to help improve the quality of their deliverables. When we discussed this project in class, since they are working on the same project, where appropriate, I would answer specific group questions that one group may have had, but I would provide the question and answer to all groups in the class. Students also would informally talk about their systems, and in the competitive project situation, students were often sharing their information and providing helpful solutions to other groups. Student feedback informed me that this aspect of being able to ask other groups about the same project was helpful in overcoming obstacles and arriving at the best possible solution. Additionally, comments received during the semester as well as those after the semester (formal school evaluations) mentioned that my answering questions was quite helpful to not only the group asking the question, but the other groups in the class as well. A fifth difference I observed was that the potential for students to cheat was much higher in the competitive project, thus resulting in less creativity in a number of situations. When projects are completed as stand-alones, each group works on a unique system with unique requirements. Thus, the potential for cheating is much less. Additionally, when each client system is unique, groups have to come up with their own solutions for problems with the systems they are working on. However, in the case of the competitive projects, the system and system requirements are the same. Further, as discussed in the previous paragraph, groups are able to share information, ideas, and thoughts, all of which often decrease the creative process and increase the potential for cheating. As a result, I did a number of things (e.g., ask for online copies of each paper so they could be compared; systematically ascertain if each student understood the system and its requirements via homework and testing) to encourage each group arriving at their own solutions and to discourage and penalize cheating. Nonetheless, instructors must be aware that the potential for cheating is elevated in a competitive group project environment. A sixth difference is the instructor ability to assist student groups with their projects. Regardless of the project, the instructor should have an in depth knowledge of the SAD material, and can use that to help students. Additionally, when the project is a competitive project with only a single client system, the instructor is able to specialize and learn a great deal more about that system than if each group had a different system. As a result, when semester projects are competitive, the instructor is able to know more about and provide more client system specific help. A seventh difference is the perceived pressure between groups. Comparing the stand-alone and competitive groups, the pressure between groups was considerably higher when all groups had to analyze and design the system for the single client (the competitive semester project). This is not meant to say that pressure is a good or a bad thing, although I believe that there is healthy pressure similar to what employees experience in an organizational setting, but just that pressure which did help to motivate the groups was different depending on the structure of the semester project. When we discussed the project in class throughout the semester, students would often discuss or show me the progress of their work. With the small class size, it is highly likely that other project groups heard parts of our conversation, and they even joined our discussion to learn more about what we were talking about. It was not uncommon at all to hear other groups say something like “wow, that’s a good idea,” “our group did such and such things for our project,” or “what do you think if we were to do this differently.” Fortunately, these students were very helpful with each other in the way that they did not view this type of intervention as a threat to their project scores (as I had told them the projects would not be graded on a bell curve, but as separate projects, and all groups could do things differently, but still receive a high grade if it was deserved). Based on personal discussions as well as end-of-the-semester teaching evaluations, students definitely enjoyed working on a real project, learning from each other, and actually wished we had devoted more time in class to the project. A last difference was the overall quality of the final deliverable. Although the projects delivered by students were strong in both the stand-alone and competitive semester projects, the overall quality of the systems was higher when the projects were on the same client. I asked some students about what motivated them to produce the extremely high level deliverable, and I often heard things related to the fact that the system was to be used by a real-world client, it would be used by their University – thus making them want to do the best job possible, and they wanted to do a better job than the other groups in class. 6. CONCLUSION Teaching the systems analysis and design class is always a challenge and many instructors have shown the efficacy in using a real world semester project. Up to this point I had always had student groups complete different stand-alone projects. However, when the opportunity presented itself, I explored the opportunity of having students complete the same real-world group project in a more competitive environment. The results, based on both the quality of work and student comments, revealed that groups felt pressure to work harder, enjoyed the competition, and ultimately produced higher quality projects. All in all, I have concluded that I will not shy away from and will actually try to have more competitive group projects, as the benefits of these projects far outweigh any potential drawbacks. 7. REFERENCES Cappel, J. J. (2002) “A Systems Analysis and Design Case: ABC Church.” Journal of Information Systems Education, 12 (4), pp. 233-243. Connolly, T. M., and C. E. Begg (2006) “A constructivist-based approach to teaching database analysis and design.” Journal of Information Systems Education, 17(1), pp. 43-54. Felder, R. (1992) “How about a quick one?” Chemical Engineering Education, 26(1), pp. 18-19. Griffeths, G. (1998) The Essence of Structured Systems Analysis Techniques. Prentice Hall, New York. Griffeths, G., and B. J. Oates (2003) “Lecture-free Teaching for Systems Analysis: An Action Research Study.” Proceedings of Informing Science and Information Technology Education Joint Conference, Pori, Finland. Hackney, R., T. McMaster, et al., (2003) "Using Cases as a Teaching Tool in IS Education." Journal of Information Systems Education, 14(3), pp. 229-234. Helwig, J. (2006) “Using a “Real” Systems Development Project to Enrich a Systems Analysis and Design Course.” Information Systems Education Journal, 4 (62). Janicki, T. N., D. Kline, J. A. Gowan, and R. Konopaske. (2004) “Matching Employer Needs with IS Curriculum: An Exploratory Study.” Information Systems Education Journal, 2 (21). Lenox, T. L., and C. R. Woratschek. (2005) “The Pros and Cons of Using a Comprehensive Final Case Project in a Database Management Systems Course: Marvin's Magnificent Magazine Publishing House.” Information Systems Education Journal, 3(24). Marakas, G. M. (2006) Systems Analysis & Design: An Active Approach. McGraw-Hill Irwin. Misic, M. M., and N. L. Russo. (1999) “An Assessment of Systems Analysis and Design.” Journal of Systems and Software, 45, pp. 197-202. Noll, C. L., and M. Wilkens. (2002) “Critical Skills of IS Professionals: A Model for Curriculum Development.” Journal of Information Technology Education, 1(3), pp. 143-154. Scott, E. (2006) “Systems Development Group Project: A Real-world Experience.” Information Systems Education Journal, 4(23). Surendran, K., I. C. Ehie, and C. Somarajan. (2005) “Enhancing Student Learning Across Disciplines: A Case Example Using a Systems Analysis and Design Course for MIS and ACS Majors.” Journal of Information Technology Education, 5, pp. 257-274. Van Vliet, P. J., and Pietron, L. R. (2006) “Information systems development education in the real world – a project methodology and assessment.” Journal of Information Systems Education, 17(3), pp. 285-294. Appendix A Differences Between Stand-alone and Competitive Semester SAD Projects Stand-alone Projects Competitive Projects Good, but different from competition projects Overall Learning Good, but different from stand-alone projects Interviews are conducted individually Interviewing the Client Better than stand-alone projects, as groups can use all information gathered and learn from each other Better, as groups gain considerable knowledge of their own client’s system, as well as exposure to other group’s client’s systems Exposure to Different Client Systems Groups gather an in-depth knowledge of one client’s system Students are able to use others’ thought processes and potentially take things other groups are doing and use them in their projects Ability to Build off of and Share Information with Each Other Students are able to ask others in class for project help (as they have the same client and system), the client interview is the same, and when project milestones are discussed, groups can use them to help each other Increased creativity and minimal potential for cheating, as all of the projects are stand-alone Creativity/Potential for Cheating Potential for decreased creativity and considerably higher chance of cheating, as groups can talk with each other and share information Some, based on instructor’s general SAD knowledge, but minimal in relation to the client’s system Instructor Ability to Help Student Groups Much better, as the instructor has general SAD knowledge and greater information about a single client’s system Minimal, as students realize that their project will be compared to others, but that the system is different Perceived Pressures between Groups Much higher (in a good way), as students are motivated to perform at an extra high level as all deliverables are on the same client and easy to compare Good, but often times not as good as possible based on potential initial holes in the client interview and minimal motivation to “one-up” other groups Final Deliverable Better, primarily as a function of the improved client interview, instructor’s better knowledge of the system, and group competitive pressures