Real-world methods The most important real-world method in use in the IS Lab is the concept of the multidisciplinary /multimedia web development team. No single person can create any kind of multimedia or web instruction alone if that instruction is to compete visually and professionally with commercial products. It would be impossible for the individual faculty member to simultaneously be a professional in all of the areas needed in development. Thus the faculty member coming into the lab to develop a web supported course becomes one member of a development team, in this case the content expert as well as a project co-manager. A second project manager, equal in authority, represents the Lab. As needed, a graphics expert, a videographer, a programmer, and an instructional designer may be assigned to the project. Each team member is a student, and all bring the latest information from their respective fields. The lab is a crucible in which these students from different disciplines must learn to work together. The graphics designer learns quickly that small file sizes are important to the web designer; the programmer learns to appreciate that it takes as much dedication and as many late-night hours to create visual perfection as it does to create the perfect program. As student team members learn to respect one another they realize the invaluable experience they are gaining: they will be prepared for the development teams that exist in their future places of employment (Crandall & Levich, 1998; Ullman, 1997.) The supervisor becomes the bridge among students from the various disciplines. In all, the Instruction Support Lab has a staff of twelve student workers, from as many of the University’s Colleges as possible. While the majority are students in Education, Engineering, Fine Arts, and Architecture, students from all disciplines have something to offer.
A second real-world method is the concept of the “flat” hierarchy. This concept is prevalent in what Pearce (1997) calls “virtual” companies: small, low-overhead companies that can expand and contract as needed. Downes and Mui (1998) report the concept as a successful strategy in development, quoting a CEO as asking, “How do you change a culture from one of hierarchy with the normal pyramid to an open, flat culture where the 25-year-old can say to me, ‘You’re crazy. That won’t work. Where did you get that dumb idea?” A flat hierarchy does not mean that the CEO is no longer the CEO, but that a system of revolving authority can allow the expert in a field to make the decisions involving that field. The expert must be willing to share information, and the other team members must be willing to learn, so that responsibility for decision-making stays with the expert only so long as the decisions involve the expert’s field. In practice, this implies that the supervisor is constantly being taught by the employees, so that the supervisor can participate in decision-making regarding the employees from an informed standpoint; and it gives employees a chance to be committed and to do their best.
A third real-world method is that of allowing staff members to manage their time. Student workers in the IS Lab are told upon being hired that they will be expected to spend approximately half their time on lab tasks shared with other Lab staff: working with drop-in clients, scanning, documenting, even dusting. The other half of their time should be spent in activities which will help them develop skills in their area of studies and interests. There may be times when as much time as possible will be devoted to a project deadline that demands that everyone contribute. However, this will be followed by time for the student to learn a new software program or to work on a project of interest.
Fourth, the Lab uses a system of networking and internships to find qualified/competent student staff. Because our work environment is unique on the ASU campus, the Lab has no trouble attracting applicants, yet we do most of our hiring through networking with former employees often recommending new students. These new students usually apply first as unpaid interns, willing give their time for a chance to learn the skills of working in a multidisciplinary team and creating professional work. Such interns are given the responsibilities of full Lab staff members. Interns are required to keep a journal and to produce, or work as a team member on, one large project that becomes a part of their portfolio and is useful to the lab. In addition to interns, the Lab has a mentoree program, in which young adults who would not otherwise have access to technology are given the status of interns in the lab. Of our four mentorees thus far, one was a learning-disabled young man; two came to us through a technology mentoring program for the formerly homeless; and one is deaf.
Fifth, the Lab relies on collaborative procedures involving electronic and face-to-face meetings, for the iterative nature of the developmental process requires collaboration (Yourdan, 1998). All students are given accounts on the Lab servers; after a recent survey of internal files on our main server it was estimated that almost one quarter were uploaded for collaborative purposes. Students working on a project may not be in the Lab at overlapping times, so collaborate by uploading their work to a shared directory on the server, then notifying the other students via e-mail of the project status. A particularly important collaborative procedure is the “studio model” adopted from the College of Architecture. Under this model, students develop in a lab environment, and a team member is encouraged to request feedback from peers at any time in the development process, even if they are not on the same team. An extension of this is the concept of the small usability study, in which an interface is tested by a group of seven to thirty users. In addition, we are currently using collaboration software in order to keep documentation and student workload information easily accessible.
Finally, as far as possible, the Lab uses real-world planning and documentation procedures. These can be difficult to implement, as neither professors nor students may see the use. However, the use of a multidisciplinary team that does not always meet face to face requires the use also of planning documents such as timelines and storyboards. Such methods contribute to the success of commercial companies, as they break projects down into smaller tasks and issues (Kristof, 199); thus they can only improve our instruction. While developers agree that a project management tool that meets all needs has not yet appeared (England & Finney, 1999), as better software for project management is developed, documentation will become an expected part of project development for all team members.