by P M AlexanderUniversity of South Africa


Computer based educational (CBE) courseware has been developed at the Centre for Software Engineering (CENSE) at the University of South Africa for close to fifteen years. A team approach was adopted from the start and has been adhered to faithfully. In addition a well defined but nevertheless fairly flexible systems development life cycle has been used. Different subject matter experts (SMEs) from vastly different disciplines have been involved in the different projects. In all cases they were novices at creating CBE courseware. The rest of the team has been stable.

It is unfortunately impossible within three pages to give a lucid argument with supporting references as to why educational computing can be considered to be an example of an Information System (IS) which is in many respects not very different from any commercial IS. Although this association applies to the use of computers in academic administration as well as in teaching and learning, it is on the latter that I wish to concentrate. Within these limitations of spaces it is also not possible to discuss or even mention all the new IS approaches, technologies and methodologies which impact on one another and affect the systems being developed. In this summary these two important discussions have been omitted and a brief description is given of the team model currently used, a few problems are high lighted and proposed changes to the team model are given. References have had to be omitted.


The concept of using teams in developing interactive multimedia (IMM) courseware is not new. In fact teams are even used in software development by MicroSoft. The generally accepted advice is: Establish functional specialties, but work in small teams and overlap responsibilities.

At a conceptual level courseware development should actively address: what is to be taught (subject matter); how (educational and technological); to whom; and in what organizational environment. The team must, therefore, contain members with expertise in each of these fields i.e. lecturers, instructional designers with IMM experience, specialist programmers and media experts. To this is suggest adding students, as well as an information systems consultant. Of course certain members may fulfil more than one role but the person fulfilling the role must be an expert and must pay full attention to the issue. The use of amateurs, particularly in the technological areas of programming and multimedia, can cause serious delays and inefficiencies. It is our opinion that many projects are abandoned because the time required for implementation and more complex programming needed are underestimated. In particular, in the case where the design sub-team also do the implementation, creativity may be limited by what is considered to be implementable. Despite having more than ten years experience as professional IMM developers and having used the same tools for several years, our programmers are confronted in every project design by new ideas that they do not know how to implement. But, more importantly, in every case they have eventually found ways of achieving the desired result without the requirements being adjusted. Thus the separation of "what" and "how", by keeping the design and implementation teams separate, not only as regards function but also team members, is essential.

Practical problems which initially appear to involve the selection of projects, but which on further reflection have their roots in the composition and functioning of teams, have occurred and re-occurred in the history of IMM courseware development at Unisa. Some of these are commonly acknowledged in the literature. The amount of time required from the SME/lecturers is a problem. We try to stick to a fixed schedule where the lecturer works on the project regularly for at least four hours each week and warn potential clients of this requirement before accepting projects. This materially affects the projects that are proposed. It tends to mean that people proposing projects generally come from departments with few and declining numbers of students. Academic staff from the departments with thousands of students in each course neither have the time nor the incentive to create IMM courseware. In addition, the lecturers who are interested in participating in this type of project are usually the "go getters" and often move on, quite frequently out of their own academic worlds and into technology or management positions. This then introduces a new problem. If the courseware has not been embedded in the department, but is seen as a "pet project" of one particular staff member, the use of the courseware may be neglected or even dropped. The use made of systems in the long term is a classic IS problem.

The problem of the amount of time which the SME has available for the project should not be side stepped by the lecturer handing over printed material to the instructional designer to "convert" into IMM courseware as this results in the loss of the teaching experience component of the requirements and an essential part of the commitment to using the resulting courseware.

The issue of motivation to participate in combined research with technology experts and the possible conflicting goals complicates the issue. The technology expert who sees the project as contributing to research seeks "hard", technology problems whereas the "client" is mainly interested in doing research in his or her own field and seeks the project as providing a tool. A need to make it worth the while of all the participants and to attract projects which would have the most impact for the students and university has also been addressed in the literature previously.


Despite the fact that the teams working together in producing IMM courseware in the CENSE have worked extremely well together, enjoyed the experience and been proud of the quality of the material that they have produced, on reflecting on the outcomes we believe that issues of effectiveness (meeting long term goals) and organizational change need to be addressed. It seems probable that the policy of accepting projects motivated by lecturers, even when these were supported by departmental heads, without actively seeking out conflicting opinions and more general commitment to the project in order to try to create a more broadly based initiative, was naive. Students at Unisa, by virtue of the fact that they are usually associated with a course only for one year, are not physically located on campus, and are seen to have low status, have not been actively included in the courseware development process (except in field tests in order to try to ascertain the efficacy of the courseware). A more substantial investigation into the attitudes of our students to the use of technology in distance education is required and this is indicated in the amended model shown above. The use of IMM will probably remain optional and peripheral unless a "critical mass" of support is obtained.

I also propose extending the existing team model to include the active inclusion of IS experts in addressing affective issues, issues related to changes in teaching and learning roles, and organizational change. These are particularly urgent when we take into account the accelerated movement towards the use of the Internet in education. This move risks being motivated entirely by technological and economic arguments and by virtue of the fact that it is relatively easy to accomplish. I am in fact in favour of using the Internet but am afraid that a simplistic approach can be detrimental. This is not intended to delay such moves but, just as a team approach is used in IMM development, so should a capable team be set up to implement all aspects of web-based teaching and learning.