hopper, 1993 [6.4, abstract, overview, toc, switchboard, references]

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.
© Mary E. Hopper | MEHopper@TheWorld.com [posted 12/04/93 | revised 04/12/13]