General
Teaching Tools
Case Materials
Creating the SIS Report
The final Social Impact Statement report consists of 6 sections:
- Executive Summary
- Description of the System
- Analysis of the Results
- Recommendations
- Reader's Guide
- Methodological Appendix
Students are encouraged to focus on the client as the report's audience, and to produce a report they feel will be helpful to the client. Because this project will often be the first one of its kind that students are asked to create, we offer some tips for heading off difficulties and sharing reports with clients.
Executive Summary
The executive summary is a page or two summary of the report. It should include a description of the report and of the system, a discussion of the significant issues discovered, and a list of the top recommendations highlighted on the page. Each of these should be keyed to page numbers in the longer report. The idea is to provide a summary that an executive can read in 5 to 10 minutes to get the basic information about the report. Summarizing information in this way is in itself a useful skill for computer science students to learn.
Description of the System
This description should include the physical, logical, procedural, and social elements of the system. The physical structure includes the machines and other hardware involved, the networks, and the physical facilities in which the system is housed (e.g. the offices). The logical structure includes the data structures and software structures involved in the system.
The procedural elements of the system include the ways in which data is gathered, collated, stored, backed up, and reported. They also include procedures for maintenance, repair, and replacement of the system, and any other relevant organizational procedures (e.g. those related to privacy protection or safety). The social elements of the system include a description of personnel and their relationships to each other and to other relevant stakeholders.
Analysis of the Results.
This section includes a discussion of those concrete aspects of the system that lead to specific concerns. These many include any single aspect of the system or interactions between aspects of the system (e.g. procedures that assume technical maintenance even though personnel are not trained). Patterns of use, patterns of oversight or error checking, specific hardware or software concerns, or specific organizational procedures are all candidates for inclusion in this section. The analysis of these specific concerns should highlight the specific risks associated with them, the probability of those risks occurring, and the likely harm or ethical concerns associated with those risks. Finally, the concrete advantages of resolving the specific concerns should be described.
Recommendations
This section should contain a set of recommendations that address each specific concern mentioned in the previous section. There should be at least two action options for each specific concern, and those options should be evaluated in terms of the client's goals and the ethical or social concerns involved. In most cases the client's goals will be multiple. For example, maintaining accurate records, guarding privacy, and minimizing cost. The effect of each option on this suite of goals should be noted. The options recommended should be carefully constructed to avoid simple black-and-white choices (e.g. safeguard privacy vs disregard privacy) and to emphasize the best available options for dealing with the issue. Technical fixes (e.g. use a different backup method) should be included as options, but should not be the only options listed. For instance, procedural changes or personnel training could also be recommended.
Reader's Guide
This should be a prose introduction to the most balanced and readable discussions of the issues that confront the client. It should include at least one item (e.g. a reader or an advanced article) that will serve as a window to further literature. This section can be organized as an annotated bibliography or as a prose review with references.
Methodological Appendix
This section should contain a rationale for the particular methods chosen, and a detailed and concrete description of those methods. The individual interviews should be noted (those privacy issues here are important) as should the specific questions asked in the interviews and any changes made in the interviews to meet needs. The description of the field observation should include a description of, and a rationale for, the observation sites and times. It should also include a description of the significant events looked for, a description of the significant events discovered, and a list of any changes made in the observation protocol made to meet needs. The description of the day-in-the-life scenarios should include a rationale for the choice of those particular perspectives and time frames, a description of the information from which they were compiled (e.g. interviews, manuals, etc.), and finally, the detailed scenarios themselves.
Heading Off Difficulties
Some students have difficulty getting started on these large projects, so it is recommended that you include interim deadline dates. Useful deadlines might be initial contacts, initial literature searches, protocols for interviews and observations, and a first draft of the report.
The interview and observation protocol deadlines are useful because the instructor can use them to make sure the data gathering is well organized and ethically thoughtful. It takes time for students to get used to the difficulty of these issues, and they will need the entire term available to them to gather the information needed, and to collect the data needed to clarify questions that arise late in the process.
Students try to have their data collection done by at least 3/4 of the way through the term. During the write-up phase, they will almost certainly want to go back for some follow-up interviews or observations, and it is good to have some time in which to do these.
Since these are often large projects, students could work in groups to complete them. However, it is reasonable to ask that every student be involved in every phase of the project (e.g. literature search, data collection, analysis, and write-up).
One way to deal with the perennial issue of unequal group participation is to ask students to rate each other (and themselves) on scales for effort, reliability, and quality of contribution. These ratings can then be averaged into each student's grade. Students who loaf can be pointed out and have their grade altered in this way. It is also useful for the instructor to reserve a "vote" in the rating, in case the entire group colludes in giving each other high (or low) ratings.
Sharing Reports with Clients
There is both a pedagogical and ethical issue involved in determining whether to share with clients the reports students have generated. This is most intense with those sub-par reports that might convince clients that they have no real difficulties to face in their systems. On the one hand a good report can be quite helpful to a client, and it is motivating for students to know that their reports will actually be used by their clients. On the other hand, a poor report might do more damage than good.
One way to resolve this issue is for the instructor to have a meeting with the client after they have read the report, and for the instructor to point out both the strengths and weakness of the report. If time permits, the client's reaction to the report could even be used as part of the students' grade.