6.4.3 The Impact of Organizational Contexts on Advanced Courseware
The major factor in the success of courseware initiatives was the degree to which
they found ways to balance their educational and technical requirements with their
organizational considerations.
Attempts to reach unique discipline and learner oriented goals afforded by new
computing capabilities led to unforeseen technical challenges and became
intertwined with issues related to traditional organizational structures
for distributing and managing human, technological, and financial resources.
When educational decisions presented technical challenges, successful projects
developed organizational structures to address the challenges. It was particularly
important that they develop ways to provide for the continuation of resources of
all types so that the project could be delivered and maintained on a regular basis.
The organizational structures which evolved to provide for the continuation of
resources depended upon the cultivation of linkages between traditional
organizational structures. There were three structures of courseware teams
that were identified that successfully provided for this linkage and the
resulting continuation of projects.
The first type of structure was the creator structure. This centered
around a key faculty member, and was the most similar to traditional classroom
support structures in academic environments. It was relatively easy to support
courseware within this structure financially, and it also implicitly supplied
needed informational resources. It was relatively easy to provide a tight
linkage between academic and computing organizations within this structure as well.
However, educators needed to devote such a large percentage of time to their
courseware that they implicitly adopted educational computing among their areas
of professional concern. A model of educational computing which requires educators
to devote a relatively large portion of their professional career to the endeavor
is clearly self-limiting in terms of how wide spread the model can become across
the curriculum in educational institutions at any level.
It was due to the limited nature of the creator oriented team structure that the
integrator structure emerged. This model was more similar to the
organizational structures traditionally used to support lab courses and
involved a major role filled by someone who was neither a member of the
faculty or the computing organization. In this study, the person was often
a graduate student with some expertise in both the discipline and computing,
and often needed to develop additional expertise in any area in which they
were less experienced. Just like lab courses, this model was financially
challenging and thus was limited in the same ways as lab structures in
traditional academic settings.
The limited financial nature of the organizational structures surrounding
integrators caused the orchestrator structure to evolve.
This structure was the least like traditional academic structures and
involved the formation of a third organization specifically designed
to support courseware creation and delivery. This structure developed
as a symptom of the fact that courseware development is an activity that
is outside of the traditional mission of existing organizations within
educational institutions. The orchestration organizational structure
was able to successfully address the need to obtain all major forms of
resources outside of traditional mechanisms. While projects created
through this structure found ways to provide resources successfully,
they faced the challenge of trying to achieve linkages back to the more
traditional academic and computing organizations.
Few academic departments or computing organizations on their own are likely
to find sufficient informational, technical, financial and human resources
available to support long term continuation of large scale courseware efforts.
In a few cases where the resources and the motivation are present, courseware
may be supported within traditional organizational structures. It will be
very productive to make provisions for faculty who wish to create courseware
by providing funding for departmental facilities to support local courseware
development and delivery.
These can be staffed by "integrators" and groups with "linkage" to traditional
academic and computing organizations and across institutions cooperations by
discipline (interdiscipline within universities and intradiscipline across universities).
In some cases, it may also be beneficial to consider a third independent organization
closely integrated into the campus involved in both software design and courseware
creation. Support from multiple computing companies might be feasible as a mutual
service to the companies who gain a good setting to experiment with software,
while educational institutions get both the immediate benefit of their presence,
and the long term benefit of more appropriate software.
It will be important to devote more resources to exploring the complex dynamics
of courseware teams. This could be a subtle factor which can seriously make or
break successful creation and continuation of projects. A particularly important
issue to understand is the dual nature of the roles on courseware teams. One way
to define roles is in traditional terms associated with particular tasks.
This type of description varies systematically based upon the types of software
functions emphasized.
[Refer to "Roles" column in Table 6.1.]
The second way to define roles is by the way they relate to
the organizations involved. Needed skills and the less obvious time, motivation,
and "linkage" factors should be considered when choosing team members for courseware
projects.