5.3 The Impact of the Organizational Contexts
The success of courseware projects depended upon provisions for continued resources
of all types. The prerequisite conditions for courseware creation were the availability
of content materials free from copyright restrictions, and the presence of a faculty
member with a well developed vision of education based upon strong discipline and
learner oriented goals. It was helpful that the faculty member also had a grasp of
the limitations of the technology and the wish to express their vision through computer
courseware. The two most important resources for the initial creation of courseware
appeared to be human and technical resources. At the beginning of courseware creation,
equipment was needed to develop the courseware, and staff were required to begin the project.
The continuation and expansion of courseware beyond its initial funding from an outside
source depended upon its evolving a structure to support the continuation of resources
of all types, while overcoming the limitations inherent in the organizational structures
surrounding the project. This way of viewing the establishment of courseware that
continued to be offered over a period of time produced a reinterpretation of courseware
creation as a process of establishing an ongoing system for obtaining and managing
informational, technical, human and financial resources while maintaining a balance
among the educational and technical aspects of the project. Three organizational
models developed to support these processes, and their nature was highly dependent
upon the type of organizational structure that existed during the software's initial
creation.
An implication of the models that evolved was the need for people who served on
courseware teams to be defined in terms of their relationship to the organizations
associated with the project. Some tasks originated in the academic context of
the project, and those tended to be performed by people closely associated with
the academic organization. Other tasks originated in the technical context of
the project, and those tended to be done by people who held the closest relationship
to the computing organization. Three major project structures developed around the
ways these roles were filled.
When a faculty member took the majority of the responsibility for the creation of
courseware, he or she was called an author or a creator. When a person like a
graduate student, who was neither faculty or a member of the computing organization,
took on major responsibility for watching over and organizing the creation of software
after the initiation, conceptualization and acquisition of resources have taken place
during the first part of the project, the role was described as an integrator. Finally,
there were cases where an independent organization emerged which was neither an academic
department, nor a part of the main computing organization, and a one or people in that
organization take on major responsibility for more than one courseware creation.
This role was referred to as orchestration. This is most likely to emerge when the
organization is also engaged in the creation of the software tools as well as courseware
support. However these do not replace the lower level structures as courseware
creation mechanisms, but instead serve as more specialized support. An overview of
the types of organizational structures and the relationships among them are shown
in the table below. The continuing analysis will explore the ways in which each of
these organizational structures develop out of distinct patterns of time and motivation
constraints. The following discussion will provide more in depth explorations of these
less traditional approaches to describing team roles.
![](Hopper_93-53.gif)
Table Types of Organizational Structures and Their Relationships