A Method for Enhancing the Success of Service-Learning Projects in Information Systems Curricula Elizabeth Wilcox1 Ilze Zigurs2 Department of Information Systems & Quantitative Analysis University of Nebraska at Omaha Omaha, NE 68182, USA Abstract Service learning is an exciting and rapidly-growing phenomenon in colleges and universities in the United States. It provides experiential education while simultaneously addressing real needs in community organizations. Given the increasing popularity of service learning, a growing number of researchers have begun to study success factors and processes for service-learning courses. However, a systematic approach to success has yet to be seen. We begin by reviewing what is known about the critical success factors for service-learning projects. Based on the key issues identified, we develop a systematic method for approaching service-learning projects. Similar in concept to information systems development methods, our method for service learning is described in terms of its philosophy, roles, phases, techniques, and deliverables. Although broadly applicable to any kind of service-learning course, this method has particular relevance in information systems. Keywords: service learning, experiential education, methodology, success factors 1. INTRODUCTION Service learning is emerging as an extremely valuable educational tool in today’s colleges and universities. Service learning is a form of experiential education in which students learn and develop their skills while addressing the needs of a community organization, with a particular emphasis on reflection and reciprocity (Jacoby 1996). Service-learning projects and courses provide a means for students to obtain real-world experience in the relatively safe environment of academia. Some estimates state that more than half of colleges and universities in the United States have a service-learning program (Eby 1998), and the quality and quantity of literature on the subject is growing. Given the importance of real-world experience in information systems (IS) coursework, service learning is particularly relevant in IS curricula. Many information systems courses already include projects for hands-on experience with concepts and techniques. But service-learning projects are unique in that community involvement is central to the course and students engage in reflection to a greater extent than they otherwise would. In addition, the special characteristics of not-for-profit, community organizations contribute to making service learning a uniquely satisfying experience. However, our knowledge of service learning and its successful application still has significant gaps. Current literature on service learning reveals some critical success factors and case studies. However, few, if any, published works draw these factors together into procedures and processes that would help achieve more systematic success in service-learning efforts. In short, the field is lacking in a systematic approach, or method, to service learning. This paper fills the gap by developing such a method through an analysis of best practices and processes. We begin with a review of the existing literature in service learning, focusing particularly on what is known about critical success factors. We then briefly review the concepts and tradeoffs in system development methods, and then bring the ideas together into a method for service learning. The unique contribution of the paper is the development of a systematic method for service learning, including descriptions of the phases of the method as well as a detailed specification of techniques and deliverables that can be used to help ensure the success of a service-learning project. 2. CRITICAL SUCCESS FACTORS FOR SERVICE LEARNING The current literature on service learning discusses critical factors much like a grocery list of needs. These needs cross many boundaries, including field of study and educational level. One of the most common success factors is the need for learning to occur and be expressed in reflection or feedback. The best projects seem to be structured to provide a “combination of thought and action, reflection and practice, and theory and application” (McAndrew 2001). Students are urged to analyze their own experiences through discussion with others (McIver and Rachell 2002). Indeed, a three-way discussion is thought to contribute to synergistic learning via “…the community members providing experience and knowledge of their specific community, faculty providing their scholarly expertise, and students serving as a ‘bridge’ between faculty and community, with each group teaching and learning at the same time…” (Citrin 1993). The literature also notes that students should be graded on their reflection and that greater emphasis should be placed on the reflection and learning process rather than the outcome of the project (McEachern 2001; Valerius and Hamilton 2001). Not surprisingly, many authors also agree that the service-learning project must be carefully chosen. Key considerations include choosing a sufficiently narrow focus while including meaningful content; developing a good organizing framework; defining success criteria; and providing for specific steps that can be carried out in an appropriate time frame. The client sponsor must be excited about the project and motivated to commit the time required. That commitment contributes to a sense of importance and accomplishment for the student team (Papamarcos 2002). There must also be a clear connection between the service-learning project and the course content and objectives (Gujarathi and McQuade 2002; McAndrew 2001). While this factor seems obvious, it can be easy to get distracted by the pressing needs of the community organization and drift progressively farther from the course content and the development of necessary skills and techniques related to that content. Developing a real partnership, while simultaneously meeting the needs and expectations of all parties, is not easy to accomplish. The most effective programs include training that helps to develop mutual understanding and shared expectations (Eby 1998). Finally, service-learning programs work best when they are optional rather than forced (Gujarathi and McQuade 2002). Although dedication to the project is demanded once it is set in motion, the best commitment comes when people engage in the project through their own choice. Such projects are complex in many respects, not the least of which is the different interests of quite diverse stakeholders (Eby 1998). Bringing those interests together takes time and effort, and stakeholders must be selected carefully so that they can work together as a committed team. Table I summarizes the critical success factors for service-learning projects derived from the literature just discussed. Table I Critical Success Factors for Service Learning Critical Success Factor Source Necessary reflection or feedback McAndrew 2001, University of Pittsburgh at Johnstown 2003, McIver and Rachell 2002 Reflection by all stakeholders Citrin 1993 Grading on actual learning McEachern 2001, Valerius and Hamilton 2001 Careful project selection Papamarcos 2002, University of Pittsburgh at Johnstown 2003 Relevance of the project to the intended academic program Gujarathi and McQuade 2002, McAndrew 2001 Partnership between stakeholders Eby 1998 Optional involvement Gujarathi and McQuade 2002 Balanced interests of all stakeholders Eby 1998 Careful selection of stakeholders Eby 1998, Gujarathi and McQuade 2002, Papamarcos2002 3. METHODS IN INFORMATION SYSTEMS DEVELOPMENT As noted earlier, a systematic method for conducting service-learning projects has yet to be developed. The IS field, on the other hand, has a long history of the use of methods for systems development projects. We believe it is useful to borrow those concepts and apply them to the field of service learning. In this section, we provide a brief review of the state of IS development methods, as a foundation for developing a method for service learning. The concept of a method means different things to different people, and the literature on methods has grown considerably over the years. For our purposes, we define a systems development method as a systematic process for the development of an information system, consisting of phases, tasks, techniques, deliverables, roles, and an underlying philosophy (Avison and Fitzgerald 1995). Key to this definition is the idea of a philosophy that explicitly states the underlying principles of the approach. For example, structured methods are built on the concept of functional decomposition and the belief that a complex problem can be decomposed into a meaningful set of parts that then define the whole. Socio-technical methods, as another example, are built on the belief that computer systems are both a social and technical intervention and that both types of goals must be defined and integrated. Many kinds of methods have been used in IS development, including structured analysis and design, soft systems method, socio-technical approaches, rapid application development, object-oriented methods, and most recently, agile methods (Avison and Fitzgerald 1995; Fowler 2002). No single approach has been proven to be the best one for all projects, although each type of method often has devoted followers. Structured methods were introduced in the 1970s to deal with the perceived proliferation of poorly-developed systems in that era. As flexibility and rapid development became more important, earlier methods were criticized for being overly controlling and documentation-oriented (Highsmith 2000). The current emphasis on responsiveness and speedy development has led to a focus on so-called agile methods. Agile methods are defined as being adaptive rather than predictive, as people-oriented rather than process-oriented, and as focused on reducing formal documentation (Fowler 2002). The development of agile methods has occurred hand-in-hand with the continuing sophistication of tools for making actual construction of software easier. Advanced tools have allowed developers to spend more time on the early work of requirements analysis and system design. Examples of agile methods include Extreme Programming (Beck 2000), Crystal Light, SCRUM, and Adaptive Software Development (Highsmith 2000). Adaptive Software Development (ASD) provides a good example of the agile approach. ASD is an iterative method that consists of three steps: Speculation, Collaboration, and Learning (Highsmith 2000). The Speculation phase defines key stakeholders and the scope of the first iteration of the system, including an approximate timeline and set of deliverables. In the Collaboration phase, the development team relies heavily on collaboration to work together and create the first iteration. The Learning phase consists of determining whether the required quality has been achieved both from customer and technical perspectives, whether the team works well and efficiently, and what the current status of the project/iteration is. The system development process proceeds iteratively through these cycles. Agile methods can be criticized for being too flexible, just as traditional methods can be attacked for being too rigid. Our purpose is not to engage in that debate, but instead to find a suitable approach from the systems development world that is most analogous to the environment in which service learning takes place. Given the earlier discussion of critical success factors for service learning, we argue that an agile approach is directly relevant to service learning. The rest of the paper focuses on developing a service-learning method based on the agile concepts. 4. A METHOD FOR SERVICE-LEARNING PROJECTS Recall that our definition of a method includes phases, techniques, deliverables, roles, and an underlying philosophy. We present our method in terms of these components, beginning with an all-important aspect that is rarely made explicit in the documentation of methods, namely its underlying philosophy. Philosophy Service-learning projects are as diverse as the disciplines and locations in which they occur. The only constant across all service-learning projects is people. For this reason, we focus our philosophy on the undeniable importance of the project participants, or stakeholders. All people who participate in the project are responsible for its success, and this brings these people together as the project team. Because each person also invests time, energy and, sometimes, money to the project, they are also stakeholders in the project. No one stakeholder has any more ability to cause success or failure than another member; they are equals. For this reason it is imperative that the stakeholders for a service-learning project are carefully chosen and that those stakeholders are aware of and actively fulfilling their roles within the project team. Our method reflects the importance of stakeholders throughout the phases and supporting techniques. As the following sections show, the selection of stakeholders and the definition of their roles is a paramount step to ensuring the success of a service learning project, and this new method allows for that within its structure. It also allows for the method to adapt to the people and circumstances of the project, through the versatility of an agile method, without sacrificing all the necessary structure of the academic environment, as seen in more traditional methods. In sum, the underlying philosophy of our method for service learning is that the stakeholders drive the process and success of the project. Phases Phases are an essential foundation of any method. They lay the ground rules and mindset for how the project should be approached, planned for, and executed. Figure 1 shows the phases for our proposed method for service learning. The phases represent a synthesis of traditional and agile elements, based on the critical success factors for service learning. The phases preserve the importance of initial analysis and final reflection, while recognizing that the real world is unpredictable. Our method reflects the volatility of service-learning situations and provides for the capability to react and reinvent the project. Just as service learning is a marriage between academia and community organizations, so our method is a marriage between the needed structure of the academic context and the unpredictability of the client’s world. Figure 1. Phases of a Method for Service-Learning Projects Project investigation Project investigation is the phase in which the professor seeks out possible service-learning opportunities. She or he discusses service learning with possible project sponsors as well as the university. This phase serves the simple purpose of testing the waters. Throughout this phase, the professor should collect project abstracts and possible job descriptions from contacts in the community, while maintaining a discussion of feasibility with university people who have the ability to accept or reject such a project. These activities should take place well before the semester of the actual service-learning project. What is important here is that the work of identifying a project is begun and enough time is provided for project initiation and analysis. Project initiation and analysis: The search for stakeholders Within the project-initiation phase, the majority of the work is done by the professor. The phase’s purpose is to get the project off the ground. To begin this process, the professor must first choose a project. Criteria should be set as to what the project should accomplish for all parties involved. For example, the project should relate to the students’ field of study and, more specifically, it must be appropriate for their level of knowledge. The project must also be feasible. Students with the proper skill sets must be able and willing to commit themselves. Also, the project must be the right size for the number of available students; it must not be so big as to be insurmountable, but it also must be too big for any one student to tackle alone. The project sponsor or contact in the community must be willing to set aside the time and be able to make any monetary investment that is needed. Finally, the professor must be sure to have the time, patience, energy and expertise to take on such a project. While many of these criteria seem obvious, they can be overlooked in the initial enthusiasm for a project, and a structured approach to evaluating the project on these criteria helps to stay focused on essentials. Service learning presents a demanding and unpredictable situation with a considerable amount of responsibility for a number of stakeholders. If the professor has any doubts about her or his ability or willingness to take on such a project, she should consider taking on a partner, or dropping the project all together. Also, the other stakeholders must be considered in the selection of a project. The necessary traits of the project sponsor, such as willingness and ability to commit time and effort to the project, have been mentioned as part of the project selection process. Furthermore, the student team should be carefully selected – their skills are important and should be weighed heavily. However, it is also important to weigh the team in terms of an overall balance. Team members should not all have the same backgrounds and skill sets; it is a team’s diversity that makes its synergies most extraordinary. Furthermore, the team must, above all else, be able to function as a team. This not only means that they must be compatible and willing to get along, but they must have the time and flexibility in their individual schedules to meet as a team. This can be a difficult criterion to fulfill on some college campuses. Once again, all of these concerns should be addressed before the beginning of the term in which the actual service learning project is to take place. After project initiation is concluded successfully, project analysis begins. These phases are considered a single phase because so many of the activities are overlapping. For example, in choosing a project, it is important that the project’s scope, or what the project ultimately should accomplish, is such that it can be accomplished in the amount of time available to the team. During analysis, the stakeholders involved further hone this decision; specific tasks that identify the overall goals of the project should be agreed upon, written up and signed. One way that this can be done is through a project plan. This technique will be explained in detail later. Ultimately, all stakeholders involved must identify what the success of the project will look like, and that vision must be shared by all involved. Beyond this point, the student team and professor must agree, or at least have an understanding, as to how such goals will be reached and how that will affect grading. These items should be thought about by the professor before the semester begins, and laid out within the first week; these aspects of the project are the syllabus of service learning. In addition, the professor should consider using a “hold harmless” agreement to protect the student, sponsor, and institution. Examples of such agreements are widely available on the Web. The “DEW” loop The “DEW” Loop is the iterative process in which the real work of the service learning experience is done. It is here that the method allows for flexibility and reinvention; it actually is founded on the idea that such adjustments will be made. The “DEW” of the “DEW” Loop stands for its three sub-phases, as explained below. Dedicate goals: This sub-phase is like a mini analysis phase. A goal that works toward the final goal of success and completion of the project is set, along with an appropriate timeframe or deadline. For example, a document or a certain number of hours worked is a goal that the student team is expected to complete within a two-week period. Because this goal is set by all stakeholders involved, the goal and its successful completion will be a measure of progress, showing the project sponsor that the students are capable and are working toward the final goal. It will also give the students confidence in their own abilities and make a large project seem more attainable, and finally it gives the professor a bargaining chip with the university and a way in which to measure the students’ progress. The goal has the same criteria as the overall project. It must be attainable, but not too simple. It must push the team to work together. It must be agreed upon by all stakeholders. And it must relate to the students’ course of study. Execute: Once a goal is identified and that goal has a deadline, the student team must work to accomplish that goal. The student team must have ownership of this step. They must manage their own time, they must acquire the skills necessary to reach the milestone, and they must have the credit for their success. Of course this does not mean that the other stakeholders should not be involved. The professor’s role becomes that of facilitator at this point. She or he is there to guide and make suggestions. Likewise, the project sponsor’s role is that of client. The sponsor must contribute at this point by providing the information necessary to continue work, but the sponsor should not be expected to do any work on the project or its documentation at this point. All stakeholders should be kept updated on progress, via e-mail, phone conversations, written updates, or weekly meetings. If any problems occur, a meeting would be preferable. It is paramount to remember that these phases are adjustable; should unexpected situations arrive that affect any stakeholders’ ability to carry out their duties, particularly the student team, the group may return to the “Dedicate goal” phase and compensate for the new challenge. Weigh feedback: After the work has been done in the “Execute” phase, it should be evaluated here, in the “Weigh Feedback” phase. All stakeholders must have an equal opportunity to evaluate the work done by all other stakeholders, including themselves. This gives each person involved the opportunity to understand what she or he did right as well as wrong, and to improve upon that in the next iteration. This is where the true learning takes place. The process of evaluation also gives the professor another chance to grade the students and to do so based on collective standards of all those involved in the project. It also gives the group a starting place for the next round of the cycle. When the group returns to the “Dedicate Goal” phase, they may already have several items that need to be reworked or continued in the next iteration. Preferably this evaluation, or feedback, could be done anonymously in order to preserve objectivity. However, the group still needs to interact in order to create the synergy that is really at the heart of the learning that service learning offers. Both of these needs can be fulfilled easily through electronic focus groups. However, not all institutions may have access to the necessary facilities to conduct such focus groups. Instead, a simple reflections worksheet could be used to satisfy the need for anonymous feedback, and the results of those worksheets could be used to facilitate a traditional focus group. All of these techniques are discussed later and templates are provided for their use. Final reflections At the end of the final iteration, a final feedback session should be used to collect the “Final Reflections” of all stakeholders. The “Final Reflections” session should be considerably longer and more in-depth than the sessions at the end of each iteration of the “DEW” Loop, simply because this time the focus of the session is not on a particular iteration, but on the project as a whole. This final session is essential for several reasons. First, it reflects on the overall success of the project as well as allowing a final opportunity for all parties to make suggestions on how to improve the process. Also, it is a final opportunity for all parties – particularly the students – to grasp all that they have learned from the experience. Finally, the information gleaned from such a session can be used to compile a summary report. Such a report can help stakeholders appreciate the project as a whole, to recognize and respect other stakeholders and their roles within the process, and it can be used by the professor to gain support for future projects. Summary reports as a technique are explained in more detail later. 5. TECHNIQUES AND DELIVERABLES Numerous techniques were mentioned in the phases explained above. These techniques are “a way of doing a particular activity” (Avison 1995). Deliverables are then the result of carrying out a technique. The next sections explain these techniques and deliverables in detail, providing examples and templates where appropriate. Project abstracts or job descriptions Project abstracts or job descriptions are the deliverables from the first phase, “Project Investigation.” These are simple write-ups, approximately a page or less in length, which describe what the actual work of the project will be. A professor may request these from the community organization if there is a specific job to be filled. If the sponsoring organization has not yet defined the project, the professor may choose to write a project abstract with the assistance of the project sponsor. The abstract or job description, which should be included in the syllabus, can be used to determine the feasibility of the project, the project’s scope, what its success would look like, and traits or skills of likely student team candidates. Appendix A shows an example of an actual project abstract from a service-learning course in which both authors were involved. Stakeholder evaluation Stakeholder Evaluation is a crucial technique in the second phase, “Project Initiation and Analysis.” This technique is used to select the teams that will represent the three sets of stakeholders: students, faculty, and clients. The importance of achieving a well-matched set of stakeholders cannot be overstated. Evaluating stakeholders can be done by interview, resume, questionnaire, or some combination of the above. A structured approach to the process helps ensure consistency. Appendix B shows a questionnaire that can be used to evaluate stakeholders. The questionnaire is based on key requirements that have been shown to be important for each stakeholder group (Papamarcos 2002). At a minimum, the questionnaire can be used to reveal areas where an existing group might need to add resources, whether financial or based on missing skill sets. Project plan A project plan is critical to the overall success of the project. Appendix C shows an outline for a project plan that is based on the typical elements of a development project (Hoffer, George, and Valacich 2002). The plan contains five parts: introduction, project description, feasibility assessment, management issues, and a timeline. The introduction contains the project overview, typically the project abstract or job description that was the deliverable from the “Project Investigation” phase. The optional project description elaborates any existing operations or limitations for the project. The feasibility analysis is a significant checkpoint for ensuring that the project is doable. Although a traditional economic analysis may seem difficult or irrelevant for non-profit community organizations, nonetheless it is important to estimate any project costs and to indicate how those costs can be covered. The technical analysis should discuss the capabilities of stakeholders to fulfill their duties; this information can easily be gleaned from the stakeholder evaluation done in the project initiation and analysis phase. A client satisfaction analysis is important to show how the project fulfills a real need in the client’s organization, including a detailed discussion of how the project may change day-to-day processes. Finally, any legal implications of the project should be addressed so that all stakeholders are aware of any legal or contractual obligations as early as possible and so that all parties agree on such duties. The section on management issues lays out ground rules and expectations for all stakeholders. Stakeholders should be identified by name, role, and any reporting relationships. Communication channels and expectations should be clearly defined. If regular meetings are to be held, their frequency and attendees should be defined. Protocols for email, telephone, or other media should be set, e.g., how quickly team members are expected to respond to an email. Finally, any management concerns or project standards should be clearly specified. This includes how the team will arrive at a finished state with any document or project, how the team will deliver its work to the client, and any other such concerns. The final element of the project plan is the task list timeline. This technique is well-understood to be important in projects but often not used as effectively as it should be. Tasks or milestones should be brainstormed, dependencies determined, and time estimates assigned. These estimates will give all stakeholders an idea of approximately what should be going on at given times throughout the life of the project. It also gives the students and faculty the familiarity of a syllabus-like document from which to work. The work of developing a project plan can be shared between the professor and the student team. The organization of such a project undoubtedly has educational value, and it may not be until the beginning of the semester that knowledge of the project reaches a level where a document of this specification is possible. Goal agendas and updates This technique is provided so that agendas for each iteration are agreed upon, written down, and updated as necessary. At the beginning of each iteration of the “DEW” Loop, the team dedicates a goal. This goal is then written down and used as a starting point for discussion at the next session. The goal is written down in the form of a goal agenda. The overall goal for the iteration may be one task, or a number of tasks, or a single task with a number of sub-tasks. To prevent the team from getting overwhelmed in their excitement to see the success of their work immediately, reasonable goals are set and broken down. Each of these tasks or sub-tasks should be prioritized in order to ensure that the most important tasks will not be shirked for less pressing desires. How the team writes up these goal agendas should be defined in the project plan. Updated formats should also be specified in the project plan. Updates are necessary when a task bridges iterations or changes in priority or definition. Updates are also necessary in mid-iteration in order to keep with the intention of the project. Such updates will certainly need to occur and should be treated as a new understanding of the goal itself. A copy of all goal agendas and their revisions should be kept as a form of project documentation. These documents will serve to help analyze the project and its processes as a whole during reflection periods at the end of each iteration and at the end of the project as a whole. Focus groups A focus group is a useful technique for reflecting on the status of the project and how the process or method used may be improved in following iterations or future projects. In service learning, focus groups can be very useful for achieving the reflection that is an essential part of success. Focus groups have been used for years and guidelines for their effective conduct are available (McNamara 1999), but the recent development of electronic brainstorming tools has breathed new life into this familiar process. Electronic focus groups are ideal for the purpose of service-learning reflections. They preserve the anonymity of individual participants while allowing the interaction of the group to create desired synergies. Electronic focus groups are conducted with tools that include personal computers and specialized groupware for each participant. Groupware comes in many forms, but for purposes of electronic focus groups, the team will need specialized software that supports electronic brainstorming, idea exchange, and idea evaluation (Atkinson 1998). Participants can react in real-time to questions by typing their answers or using a predetermined rating system, much like the example questions and rating systems in the reflections worksheets. These answers then shape electronic discussion, which appears much like instant messaging. Because users are typing and not speaking, their reactions remain anonymous, and therefore users are free to express any thoughts that they may have without inhibition. The electronic environment also allows for interaction between users through discussion forums that allow for the synthesis of thoughts and reactions, resulting in a greater number of ideas than may have otherwise been produced. The advantages of this approach include broader participation, thoroughness, efficiency, learning, and accountability (Atkinson 1998). However, this approach may not be appropriate in all situations. The resources may simply not be available to conduct such meetings. In such cases, a simple chat facility, discussion group, an intranet, or even email can be used. Disadvantages may be too cumbersome to justify using an electronic approach. Disadvantages include change from traditional or comfortable methods, a lack of necessary experience, typing may be slow for some participants; text is not as expressive as live discussion may be, and computer interaction may seem impersonal (Atkinson 1998). If, for whatever reason, electronic focus groups are not to be used, a service-learning team may use a more traditional focus group technique in conjunction with an anonymous reflections worksheet. These worksheets should be completed before a focus group session and, if at all possible, given to the focus group facilitator. Once the facilitator has these worksheets, she or he can review them and compile a list of common concerns or unexpected results. These issues will then shape the agenda and discussion of the focus group. The disadvantage to this approach is that the facilitator must do slightly more preparation for the actual focus group session and that anonymous interaction is never truly achieved. Within our proposed method, focus groups can be used at the end of each iteration of the “DEW” Loop, as well as during the final reflections phase. Issues to be discussed in both of these focus groups are provided in the reflections worksheet. If the electronic approach is used, then the focus group can be facilitated directly from these worksheets. If the traditional approach is used, then these are the worksheets that should be filled out before the session and used to build the session’s agenda. Reflections worksheet The reflections worksheet should be used at the end of each iteration of the “DEW” Loop, in one of two ways. Either it should guide discussion in an electronic focus group or it should be completed by each stakeholder prior to a traditional focus group. The purpose of the reflections worksheet is to guide the stakeholder through her or his thoughts on the milestone recently completed and to collect those thoughts in an anonymous manner so that they can be used by the project facilitator, or professor. The facilitator can then use completed reflections worksheets to guide discussion in a focus group; the focus group should provide more detailed information about that particular issue as well as allowing the group to hear other stakeholders’ views and react to them. The culmination of this information should be used to improve the overall service-learning experience for all stakeholders. To accomplish these goals, the reflections worksheet should be well thought out and formulated to meet the particular needs of the project. It may even be necessary to rewrite the reflections worksheet for each iteration of the “DEW” Loop. However, there are some questions that should be asked with each reflections session. These are illustrated in the sample reflections worksheet in Appendix E. Final reflections worksheet At the end of the final iteration of the “DEW” Loop, the “Weigh Feedback” phase should be substituted with the “Final Reflections” phase. In this phase, a final reflections worksheet should be completed by all stakeholders. This reflections worksheet is very similar in purpose and design to the general reflections worksheet. The difference between the two is the scope; the reflections worksheet is focused on the stakeholders’ reactions to the recently completed milestone, and the final reflections worksheet is focused on the stakeholders’ reactions to the project as a whole. Otherwise, the purpose and required careful formulation of questions are the same. Also, just as the reflections worksheet could be physically completed by each stakeholder, or could be used to guide discussion in an electronic focus group, the same can be said for the final reflections sheet. Again, there are some questions that should be answered regardless of the project. These are shown in the sample final reflections worksheet found in Appendix F. Summary report The summary report should be completed by either the professor or the student team in the final reflections phase. The purpose of this report is to show the results of the project as a whole and the project’s impact on all stakeholders as shown in the final reflections worksheets and/or focus group. The report should follow a simple format. For example, the report might follow the format of the project abstract being listed first, next the project team could be listed with roles assigned to each of them. The project plan should follow with both the projected and actual timeline shown. Summaries of each focus group could be inserted next. Any project specific documents should be enclosed at this point. Finally, the results of the final worksheets and or focus groups should be summarized. The length and depth of this section is largely at the discretion of the writer, but items such as the stakeholders’ feelings of success and impressions of learning should be included. This is a useful report for evaluating the overall success of the project. This document also will undoubtedly illustrate the large amount of work done by all stakeholders and be a good document to present for future service-learning endorsements. 6. ROLES In service learning, the presence and dedication of three sets of stakeholders are crucial to the success of the project. No single group of stakeholders is any more important than the other two. The next sections discuss the individual roles of each group of stakeholders. Project sponsor The project sponsor’s role is to support the student team with needed information and organization perspective so that the team can successfully complete its duties. Ultimately, if the project sponsor is not willing or able to dedicate herself and all necessary resources, then the project operates at a sizable disadvantage and is therefore much more likely to fail or even to never get started. Professor The professor’s role is that of resident expert and facilitator. She or he should step in and do actual work on the project only in emergency situations. She should instead focus her energies on ensuring that the student team possesses the skill sets necessary to complete its work and obtains the information from the project sponsor that is needed to clearly define project goals and requirements. The professor should also ensure that the expectations of the sponsor are met. Setting reasonable expectations in terms of both project scope and deadlines is a key to the success of the project. In some respects, the professor is the “social-emotional” leader of the team (McGrath 1984), at least from the perspective of exercising leadership and role-modeling for how expectations and communication need to be managed. The professor also acts to some extent as gatekeeper between the student team and the project sponsor. Students The student’s role is both the simplest and the most difficult. Students are task leaders (McGrath 1984), focusing on meeting project goals while keeping an eye towards skills that they are learning and how each skill and experience relates to material from lecture or texts. The other major role of the student is to be inquisitive and assertive. Should any student ever have a concern or question, it is her or his duty to bring that issue to the attention of the professor as soon as possible. 7. CONCLUSIONS This paper has made several contributions. First, we have provided a review and synthesis of critical success factors for service learning. Second, we have developed a systematic method for service-learning projects that defines a complete set of phases and associated techniques, deliverables, and roles. Third, we have provided specific examples and templates for key techniques and deliverables. These templates can be used as a starting point for actual service-learning projects. The method and techniques are designed to be applied in a semester-long course. Even though the planning and documentation requirements take time, we believe they are essential in starting to train students to see documentation as a necessary byproduct of a project. Documentation should not be an end in itself, but it is essential to have appropriate, streamlined, and accessible documentation. A repository and easy Web access for templates can help make the process more streamlined and accessible. Although our method has not been formally tested, it was developed from a set of established processes in the field of information systems development. A natural next step is to undertake a detailed case study of the method in practice. The continuing evolution and use of a systematic yet flexible approach to service learning has real potential to enhance the effectiveness of information systems curricula. While many courses in information systems use student projects as a way to practice development techniques, these projects rarely focus on service learning nor are they the focal point of the course. The method and processes described in this paper provide a useful and important way of reaching out to the community while developing a broad range of skills and understanding in students. The techniques in this method that are specific to service learning provide a useful addition to the normal portfolio of practices for student projects. The method is also useful in other fields, such as social work or education, where service learning may be used more often, but where information system’s methods are less familiar. 8. REFERENCES “Academic Service-Learning: A Resource for UPJ,” retrieved 12 Feb. 2003, http://www.pitt.edu/~jdarling/ServiceLearning.pdf. Atkinson, D., 1998, “Evaluating Teaching/learning via Groupware Focus Groups.” In Black, B. and Stanley, N. Teaching and Learning in Changing Times, pp. 22-27. Proceedings of the 7th Annual Teaching Learning Forum, The University of Western Australia, February 1998. Perth: UWA, http://cea.curtin.edu.au/tlf/tlf1998/atkinson-d.html Avison, D. E. and Fitzgerald, G., 1995, Information Systems Development: Methodologies, Techniques and Tools, McGraw Hill, London. Avison, D. E. and Fitzgerald, G., 2003, “Where Now for Development Methodologies?” Communications of the ACM, Vol. 46, No. 1, pp. 78-82. Beck, K., 2000, Extreme Programming Explained: Embrace Change. Addison Wesley. Citrin, T., 1993, “Linking Community Service with Independent Studies,” in Howard, J. PRAXIS I: A Faculty Casebook on Community Service Learning. OCSL Press, Ann Arbor. “Community Service-Learning Initiatives Bridge the Gap Between America’s Technology Haves and Have-Nots.” Chronicle of Higher Education. 5 July 2002, Vol. 48, Issue 43, p. A28. Eby, J. W., 1998, “Why Service Learning is Bad,” retrieved 12 Feb. 2003. http://www.messiah.edu/agape/pdf%20files/wrongsvc.pdf. Fowler, M., 2003. “The New Methodology,” retrieved March 11, 2003, http://www.martinfowler.com/articles/newMethodology.html. Gujarathi, M. R. and McQuade, R. J., 2002, “Service-Learning in Business Schools: A Case Study in an Intermediate Accounting Course.” Journal of Education for Business, Vol. 77, Issue 3, pp. 144-150. Highsmith, J., 2000, “Retiring Lifecycle Dinosaurs.” Software Testing & Quality Engineering. Hoffer, J. A., George, J. F., and Valacich, J. S., 2002, Modern Systems Analysis & Design. Prentice Hall. New Jersey. Jacoby, B., 1996, Service-learning in higher education.  Jossey-Bass Publishers, San Francisco. McAndrew, A., 2001, “Service-Learning: Benefits, Challenges, and Strategies for Success,” retrieved February 12, 2003. http://asccsa.unco.edu/students/AE-Extra/2001/1/ServiceLearning.html. McEachern, R. W., 2001, “Problems in Service Learning and Technical/Professional Writing: Incorporating the Perspective of Nonprofit Management.” Technical Communication Quarterly, Vol. 10, Issue 2, pp. 211-224. McIver, Jr., W. J. and Rachell, T., 2002, “Social Informatics and Service Learning as Teaching Models.” IEEE Technology and Society Magazine, Vol. 21, Issue 3, pp. 24-31. McGrath. J. E., 1984, Groups: Interaction and Performance. Prentice-Hall, Inc., Englewood Cliffs. McNamara, C., 1999, “Basics of Conducting Focus Groups,” retrieved April 7, 2003. http://www.mapnp.org/library/evaluatn/focusgrp.htm. Papamarcos, S. D., 2002, “The ‘Next Wave’ in Service-Learning: Integrative Team-Based Engagements with Structural Objectives.” Review of Business, Vol. 23, Issue 2, pp. 31-38. Valerius, L. and Hamilton, M. L., 2001, “The Community Classroom: Serving to Learn and Learning to Serve.” College Student Journal, Vol. 35, Issue 3, pp. 339-344. APPENDIX A SAMPLE OF PROJECT ABSTRACT This hands-on service learning course requires the student to work on a real-world project in the field with support from a graduate assistant team leader and members of the faculty. The student will work as a part of a team designing and developing the Mayor’s Hotline System. The team will be provided with: (1) A Concept of Operations Document prepared by the team leader, (2) the User Requirements Specification gathered by the previous student team, (3) a partially operational prototype developed by the previous team, and (4) a database schema from the current Mayor’s Hotline System database. The team will be required to (1) create a project plan for development of the project, (2) program the needed routines for handling calls into the Mayor’s office according to the user’s requirements, and (3) design a new database if needed. APPENDIX B QUESTIONNAIRE FOR STAKEHOLDER EVALUATION (adapted from Papamarcos 2002) SECTION 1: STUDENT. Rate each student candidate on each of the following items, using a scale of 1 (poor) to 7 (excellent). 1. Desire to serve the community 2. Maturity and judgment 3. Commitment to carrying out the work 4. Willingness to subordinate individual interests to group achievement 5. Willingness to negotiate 6. Interpersonal/communication skills 7. Relevant technical expertise 8. Creativity and critical thinking skills 9. Ability to deal appropriately with confidential organizational and/or personal information 10. Student’s specific area of expertise: Total Score for Student Candidate (maximum of 63 points): SECTION 2: FACULTY. Rate each potential faculty member on each of the following items, using a scale of 1 (poor) to 7 (excellent). 1. Commitment to service-learning concept 2. Project management skills 3. Technical expertise 4. Managerial skills 5. Ability to motivate the team 6. Tolerance of ambiguity 7. Respect for abilities of the students 8. Willingness to relinquish control to the service-learning team 9. Ability to deal with the client 10. Ability to deal with the student team 11. Availability 12. Willingness and ability to create an open, respectful forum in class 13. Understanding that service-learning is a shared learning experience 14. Access to administrative and financial resources 15. Ability to tolerate potential failure of the project Total Score for Faculty Candidate: (maximum of 105 points): SECTION 3: CLIENT. Rate the potential client on each of the following items, using a scale of 1 (low) to 7 (high). 1. Sense of importance of the project 2. Commitment to success of the project 3. Clear idea of goals of the project 4. Extent to which expectations are realistic 5. Willingness to disclose sometimes difficult information 6. Sense of urgency of project 7. Willingness to provide timely feedback 8. Extent of accessibility 9. Willingness to listen 10. Degree of technical ability 11. Extent of cognitive flexibility for innovative solutions 12. Probability of attendance at meetings 13. Likeliness of financial commitment for project expenses Total Score for Client Candidate (maximum of 91 points): APPENDIX C OUTLINE FOR PROJECT PLAN (adapted from Hoffer et al. 2002) 1.0 Introduction 1.1 Project overview 1.2 Project description 1.3 Limitations and concerns 2.0 Feasibility analysis 2.1 Technical – skills of team to carry out the project 2.2 Operational – management and organizational issues 2.3 Economic – estimated costs and benefits 3.0 Process plan 3.1 Stakeholders – team members and roles 3.2 Communication – norms, tools, expectations, format, frequency 4.0 Timeline – list of tasks and estimated completion APPENDIX D SAMPLE GOAL AGENDA Goal 1: Develop a working database schema Complete by: 5/1 Objective 1: Create a data model Complete by: 4/10 Objective 2: Assign and validate data types Complete by: 4/20 Objective 3: Review final data model with the client Complete by: 5/1 Goal 2: Implement database schema Complete by: 5/29 Objective 1: Write schema creation queries Complete by: 5/15 Objective 2: Test schema creation queries Complete by: 5/22 Objective 3: Run schema creation queries Complete by: 5/29 APPENDIX E REFLECTIONS WORKSHEET 1. List the major goals for this milestone. 2. List individual tasks completed for this milestone. 3. List group tasks completed for this milestone. 4. Rate your individual performance on a scale of 1 (poor) to 7 (excellent) 5. Did all team members contribute equally? 6. If not, please explain. 7. What were the most beneficial or productive aspects of this milestone? 8. Describe suggested improvements you have concerning the workflow used to complete this milestone. 9. Describe suggested improvements you have on tasks and goals completed for this milestone. 10. Describe what you feel should be the goals for the coming milestone. APPENDIX F FINAL REFLECTIONS WORKSHEET 1. List the major goals for this project. 2. List individual tasks completed for this project. 3. List group tasks completed for this project. 4. Rate your individual performance, on a scale of 1 (poor) to 7 (excellent). 5. Did all team members contribute equally? 6. If not, please explain. 7. Describe the most enjoyable aspects of this project for you. 8. What were the most beneficial or productive aspects of this milestone? 9. Describe your suggested improvements for the workflow used to complete this project. 10. Would you do the project again if presented with the opportunity? Explain. 11. Describe your personal contribution to the community organization with which you worked and your recommendations for future service-learning efforts. 1 ewilcox@mail.unomaha.edu 2 izigurs@mail.unomaha.edu