5.3.2 The Integrator Organizational Structure
Limitations implicit in the "creator" structure lead to the next organizational
structure of courseware teams. This structure was characterized by a unique role
that was consistently referred to by that term "integrator" in a number of contexts
during this study. The main way in which the role of "integrator" was defined was
by what it was not as much as by what it was. The people who were defined as
"integrators" were people who maintained a large part of the responsibility for
the development of courseware, but who were neither faculty nor members of the
main computing organization in the university. The general relationship between
the "integrators" and the faculty who began the projects can best be described as
"partnerships."
The first example of a project which employed this organizational structure was
the ESCAPE project. The faculty member who initiated and managed this project
was a senior tenured faculty member who played a key role in a number of major
activities in the broader department and university of which he was a part.
This required a great deal of responsibility which was a key limitation preventing
a "creator" structure in which he could perform a major part of the actual development
in addition to his role as director of the project. In the passage below, he reflects
this constraint. (W. LeBold, personal interview, July 2, 1992)
Hopper: What would have been done differently if you got a chance
to do it all over again?
LeBold: Well, with the kind of responsibility I have, the way I think I work
best is to get things started, and then turn those things over to other people.
For example, when there was a need at in Engineering at Purdue for a women's program,
A counselor-tutorial program for high-risk students, or an under-represented
minorities program, we identified that the programs were needed, and I played
a role in identifying the problem, suggesting the research and information that
were relevant, suggested plans of action, and possible methods of evaluation.
In other works more than just saying, "Here's a need." But I didn't want to
get involved in the nitty gritty of administration. I don't think that is
necessarily my long suit. So my idea for this engineering career system,
is to get it going. There's just tremendous amounts of information out there,
and the problem is how to tap those things and integrate the information so
that it helps students. If this was the only thing I had to work on, it would
be different. But ESCAPE is only a small part of my overall responsibility.
Due to this reality within the academic organization, another role needed
to develop to provide for the development. In the Fall of 1988, the Engineering
project was to play a role in an experimental engineering career development course
that was to be offered. Dr. LeBold hired Mary Hopper as a teaching assistant.
During an interview between LeBold (personal interview, July 2, 1992) and Hopper,
the term "integrator" was used to refer to the type of role that developed:
Hopper: What do you think were the major needs in developing the
Engineering Career System?
LeBold: We recognized that a need to develop an Engineering Career System for
Engineering students and graduates. We also recognized the potential of interactive
computerized systems to provide the types of career information needed. We also
recognized that existing computerized career information systems did not provide
the detailed information that engineers need. We also felt that the linking and
indexing systems available in HyperCard and the User-Friendly nature of the
Macintosh provided a fertile area for experimentation. In addition, there is a
real need for what I call integrators, and there aren't very many people who do
that job. You've got a lot of people who are specialists in developing detailed
technologies and are doing their own thing, but there are not too many integrating
people, with fingers in lots of pies, and who are able to tap into all kinds of things.
But that's the solution. We need to be able to have more integrators. Whether that
will be the future instructional designer, or whatever they are going to be called.
But, I also think it's going to have to include people with significant knowledge
in subject matter areas, as well as people who are knowledgeable about the emerging
computer information technologies. And they're going to have to have resources
available to them. Resources include personnel, equipment, space and adequate funding.
We managed to do quite a bit with rather minimal resources, but it required a longer
period of time, as well as personal sacrifice and commitment. In retrospect the time
was a plus because newer, more accessible and less expensive hardware, software,
and networking became available and made our aspirations more feasible and less frustrating.
The key to the organization of the project was the need for a number of different
roles to coexist in a single person. As technical issues increased, the roles
expanded to require not only the traditional academic tasks of information organization,
presentation, writing and publication, but also technical skills in interface design
and programming. This structure appears to have been the most commonly used across
all the institutions and projects studied during this research. The following describes
the most common situation during the Athena project, along with why this tended to
be the case:
The faculty member would develop the pedagogical concept and lay out the
general functionality of the software. Students or professional staff hired for the
task usually did the actual programming, although in some instances the programming
was part of a thesis project. (Champine, 1991, p. 73)
During the TODOR, LaVin served the in the organizational role of "Integrator".
What appeared to be critical about her role was that she incorporated here academic
knowledge of the content and learners in the Fluids Section with programming ability.
In the passage below, LaVin (personal interview, October 2, 1992) describes her own
role in the project.
LaVin: Ours was the largest of the Athena funded projects with 12 faculty
and a dozen students every year at a time. I think having a person in my position to
keep track of things was very important. A lot of what I did was keep track of where
the students were. We would have large group meetings once a week, and I would organize
them to make sure everyone came. The students all attended regularly, and I was always
there. Sometimes the faculty members came. Earll Murman would come more often than the
others. He was in charge of the whole thing, and he wanted to keep an eye on what was
going on. After the first year, we had one of the students present the work they were
doing each week. The students would demonstrate their code that was working.
I usually knew what they were doing because they would see me a couple times a week
to talk about what was happening. Presenting in the meeting gave them a concrete goal
to work towards. Some of it was motivation, and some of it was so that
everybody else could see interesting ways of doing things that people had come up with.
Over the course of the courseware development, the role evolved to include more
responsibility. For example, the role also included teaching as well as development.
So, in a lot of cases, I acted as a sort of expert TA for the class that were using
the modules, and then I would come to class sometimes and present the module in lecture
and say here's this and so the faculty member would be there and I would sort of
demonstrate it, he would talk through it , or something, or sometimes, near the end
of the project, the faculty member would just not come to lecture and say Anne, go and
talk about this module.
In projects where an integrator oriented organizational structure evolved,
a different model of continuation was described. Projects that included an "integrator"
resembled traditional lab structures in terms of resources. It is not surprising that
the universities in which these projects developed would then chose to recognize and support
them in similar ways as well. This does pose a problem for some courseware endeavors,
because just as departments differ greatly in the degree to which they can support
lab courses, so they differ in the degree to which they will be able to support
courseware projects that serve as a resource for the department.
ESCAPE was a project that fell into this category. One goal of this project was
to provide access to a high quality expanding database of problem-solving materials.
In addition, as video, and related telecommunications technologies evolve, the use
could be extended beyond geographical limitations to a wide variety of settings
including the home, the work place, libraries, museums, and community centers
providing national and international electronic access to engineering career guidance.
Other long range goals of this project are to phase it in to existing freshman courses
so that all entering students could be introduced to ESCAPE, beginning with those
students who are the most at risk of leaving engineering before graduation.
While the initial focus has been on first and second year engineering students,
ESCAPE materials also have potential for extension to students in upper division
undergraduate and graduate students, in related fields, and in other higher educational
institutions. In addition, the director would like to use mini versions of ESCAPE
to help high school students explore engineering careers.
(W. LeBold, personal interview, July 2, 1992)
Hopper: Do you think our effort has been successful?
LeBold: Yes, it is a success. The primary success is that we
showed that it was feasible to do it; it does meet a very important
need, and it could be expanded.
Hopper: Now of these, which seems to be the most important?
LeBold: Personalized Engineering career guidance is needed. There is no
question that there is a need out there. We documented it. It's a pervasive
need that goes back a long time. I'd say the need is there, and it's not really being met.
I think the plus is, we are now have information resources, and the techniques to be able
to retrieve that information. I would like to have more resources to develop more materials.
I would like have the resources to tap the tremendous information resources that are
available. I also think a lot of us realize that we need to integrate academic counseling
with the academic program. So building it into courses that all of the students are taking
will be important. But we are never going to get enough Mac labs to handle 1000 or 1500
students; the Sun workstations are one of the best practical ways to do it. And I do know
that even the personal computers are essentially going to become workstations anyway.
I would like to have the resources to move the system to the PC workstation. The thing
that is still very attractive about the Macintosh environment is that it is so friendly,
and it's so easy, and there's so many tools available for hypermedia development.
The other thing is, we could open it up to the rest of country, and the rest of world.
If the history of the current project is an indicator, the broad spectrum of goals
outlined above will gradually evolve as the supporting technologies mature, and the
databases required became more accessible. Such ambitious long term goals raise
questions about methods of support and maintenance. In the Purdue environment,
it appears that this gradual evolution of courseware over time within the context
of a functioning project is one that could be successful. For projects like ESCAPE
and TODOR, that grew in settings were lab courses are common, there is an existing model
that can be adopted. In at least one case, Earll Murman, the director of the TODOR project,
highlighted the similarities in the experiences of traditional lab courses, and the
development of courseware.
Most efforts have proven to take considerable commitments by faculty and
a supporting staff of professional and student programmers. It is probably fair to
conclude that a typical software module used for a single lecture or assignment cost
at least $20K and took a year or more to develop. The most successful projects involved
faculty teaming up with professional staff to develop and deliver courseware.
An infrastructure similar to that which supports traditional laboratory subjects
is needed for ongoing development delivery and maintenance of courseware. ...
There are many similarities between delivering electronic courseware and traditional
laboratory experiences. Both require careful conceptualization and smooth delivery
to achieve educational success. A small flaw can ruin the whole experience. Also,
both are expensive to develop and need a staff to support the faculty. Most departments
at MIT do not have a budget for this and it may need to be a centrally provided resource.
It seems clear that universities will have to collaborate in the development,
maintenance, and testing of courseware. (Murman, 1989, p. 1-6)
It seems relatively straightforward to suggest the expansion of this model to include
the creation and delivery of courseware materials. It is also clear that while a
university might provide initial funding, it is more likely to just provide the raw
computing resources. In situations where this model developed, there was also a very
strong departmental emphasis surrounding the projects. The preference and general
support for this type of model is also clear within the recommendations provided by
the committee that reviewed the Athena Project, before it became part of the institute:
For the long term, MIT must aim high, and must advance academic computing
on the multiple fronts that we recommend as a continuation of Project Athena. For the
short term, if choices prove necessary, MIT must favor strategies that extend academic
computing widely within the MIT community rather than strategies that concentrate
resources more narrowly; it thus must favor Basic Educational Services and Tools for
all rather than specialized Educational Development Projects....
To choose within each group of options, we consider several principles.
Academic computing should be inclusive rather than exclusive, interactive rather
than divisive. Academic computing should be available on the three or four computer
platforms most commonly used at MIT to maximize access and participation.
Academic computing at MIT should exploit commercial software and software developed
else where whenever feasible, parallel to hardware and software, to help faculty
members and students use equipment effectively and efficiently. Academic computing
should be organized as other academic activities are--along School and Department lines--
except where centralization will produce clear benefits. And MIT should allocate
resources to ensure a proper foundation for raising external funds and to maintain
important activities unlikely to receive external support.
(Committee on Academic Computation for the 1990'S and
Beyond, 1990, p. 19)