For many institutions, the adoption of a course management system (CMS) begins as a “small” initiative with a few interested faculty, a step that quickly results in hundreds of course sites residing on one or more campus servers. Seemingly overnight, decisions related to the use of such tools—decisions that might once have had easy (sometimes even obvious) answers—are tied inextricably to issues of academic freedom, intellectual property, and system security. Developing an understood and accepted set of policies and procedures for CMS usage begins to make sense.
Schools with established distance education programs typically have policy manuals in place, having dealt with issues over time related to course access, information security, student services, etc., regardless of the delivery method for instruction. (For more on structuring policy for such programs, see, for example, Gellman-Danley & Fetzer, 1998; or King, Nugent, Russell, Eich, & Lacy, 2000.) This article is not intended for individuals working in these programs; rather, it is aimed at instructional or technical support staff who may find themselves—ready or not—charged with devising a policies and procedures manual or related documents. The following sections include an overview of what policy is, why it’s good to spell it out clearly, and several practical ideas about organizing and writing a policy manual. (One cautionary note: in some work settings, use of the word “policy” is reserved for specially approved administrative or regulatory activities. In these cases, terms such as “recommended procedures” or “approved operations” may be preferable.)
For the purposes of this article, policies are defined as “the procedures, codes, and rules, written and unwritten, used to structure present and future decisions” (DiPetta, Novak, & Marini, 2002). Policy development is often more a process of articulating the bases for decision-making than of formulating rules from scratch, and should take place early in the implementation of a CMS. The reality, however, is that “decisions frequently outrun policy,” especially in fields that evolve quickly, and “the more urgent nature of decisions as opposed to the deliberative nature of policy” may result in a lack of planning (Fincher, 1999).
Why Bother with Policy Development?
When an institution adopts a course management system, having “rules” for how it will be used may seem unnecessary and bordering on nit picky, especially if the software is used primarily to support and enhance traditional face-to-face instruction. A policy manual, however, is an excellent way to codify procedural issues, and adopting a uniform set of policies provides numerous advantages over seat-of-the-pants decision-making. Additionally, should the institution’s online learning initiative evolve to offer fully-realized academic programs online, the essential policies will have developed organically, a factor that Schreiber (1998) identified as indicative of successful distance education programs. The most obvious reason is to ensure consistency in how things are done and how others are treated. By operating under an agreed-upon set of policies, day-to-day management activities need not depend on individual personalities, ethics, favors owed, or other variables.
Another reason to adopt a set of policies is the time savings that can be realized. By not having to consider each decision as a unique situation, administering a course management system becomes a relatively uncomplicated process in which procedures can be implemented without waiting for dictates from upper management. When a new staff member comes on board, the “how we do things here” element of managing a CMS can be quickly learned. Another advantage includes the potential for enhanced program credibility, particularly when policies are approved and backed by high-level administrators—the Provost/Chief Academic Officer or Chief Information Officer, for example. Finally, having policies codified reinforces and facilitates the collaborative nature of e-learning support. Successful implementation of a course management system requires communication among entities responsible for instructional, technical, resource/library, and administrative support, at a minimum. Clarifying how (and when, where, why, and by whom) decisions will be made can be a significant team-building exercise.
Who Should Create Policy?
In most cases, the logical choice to formulate CMS policy are the staff members who work with the system every day and who understand the needs of the end-users, the technical limitations of the software, and/or the organizational processes that govern how things get done. (Frequently, these are separate individuals.) Getting feedback from technical support staff can ensure that policies aren’t based on unrealistic expectations for system performance, while faculty representation offers an end-user perspective on how the software actually gets used.
What Types of Policies are Needed?
For those institutions using a CMS to supplement face-to-face classes or to provide resources and tools for hybrid courses, a relatively limited range of policies and procedures may suffice to guide decision-making, at least initially. (Full-blown distance education programs would require a much broader range of policies dealing with everything from student registration to financial aid to whether an independent academic calendar is to be followed, for example.) Although the focus of such policies may be narrow, it is critical that they be carefully integrated with existing institutional policy. In addition, a clear understanding of the purpose and audience for the policy document will help to determine appropriate categories (e.g., if the policies are to be used primarily to guide decisions regarding technology upgrades, this document will look very different from one used mostly for recommendations related to faculty development and training). In any case, the following categories suggested for inclusion will rarely, if ever, all appear in the same document and there are certainly others not listed that may be essential at some institutions.
The broad categories of policy proposed here—Administrative, Site Management, Academic Concerns, and Technical Issues—provide a structure with which to begin. Administrative could be considered the “legalities” area, and includes policies related to licensing, access and security, copyright, and intellectual property rights. Site Management is pragmatic in scope and deals with creating, maintaining, archiving, copying, and deleting course sites. Academic Concerns include topics related to training, instructional support, and compensation. Finally, the Technical Issues category deals with tech support, size limits, authentication, and system integration with other software.
Administrative
Licensing. Most, if not all, CMS packages are licensed annually, rather than purchased outright. Therefore, it may be beneficial to specify on whose authority or recommendation the decision to renew—or not—is made each year. An explanation of how the system is evaluated prior to the decision, or specific factors taken into account, may prove helpful in the long term, especially in the event of staff turnover. Questions to consider might include, “Will faculty have input into decisions that may significantly change their instructional options?” and “Will special initiatives need to be established, such as a student technology fee, in order to ensure adequate funding for uninterrupted use of the software?” Security. With computer viruses, worms, and the threat of hackers on the minds of IT staff at every institution, planning for system security is a routine element of tech support. Some concerns specific to CMS support might include whether students will be allowed to post files directly to a course site (by attaching files to a discussion board posting, for example) or whether users will have the ability to retrieve e-mail addresses from within the system. Access to student information, such as ID numbers or grades, must also be tightly secured and care given to ensure that user roles (especially those that allow access to student data) are judiciously assigned.
Copyright. Virtually all reputable institutions have copyright policies in place, and it would be prudent to include links to relevant sections of those policies. At a minimum, it’s a good idea to give a nod toward the institution’s official interpretation of the Fair Use Guidelines and/or TEACH Act and how these relate to the use of the CMS, especially for posting course materials. Questions typically addressed by these policies relate to whether password-protecting the course sites provides adequate protection against infringement concerns, and the suggested procedures for obtaining permissions from copyright holders. If options for using online reserves for library materials or virtual course packs are available, information on these choices could be included in this section, as well.
Intellectual Property. Here, also, the institution probably has established policies governing ownership of works created by faculty and staff. Providing a link to these policies, along with a concise explanation of how they apply to course sites in the CMS, can offer reassurance (or fair warning) to faculty considering the use of online tools and teaching materials. One consideration that may be unique to the
CMS environment is whether faculty are able to take their course sites with them to a new institution, should they change jobs, or for new faculty to bring their sites with them. Most systems allow sites to be downloaded into a compressed file, stored on CD, and later re-uploaded to a different server (running the same CMS, typically).
What a school may not have, however, are policies regarding student-created materials that are posted online. Most systems enable faculty to retain discussion postings after the course ends, and instructors may expect students to post assignments and group work within the course site, as well. Are faculty expected to inform students of this, or must they receive written permission to display student work to those outside the course? Additionally, a statement regarding ownership of system performance or usage data may be included in this section.
Access. This may be the area that most obviously requires the establishment of policy. Issues related to who will have access to course sites (and for how long) can have implications for copyright, privacy, network security, and instructional planning. Questions these policies might answer could include, “Will students have access to the CMS if they’re not enrolled in a course using the system?” or “How soon before a semester’s start date will course sites be made available to students?” or “How many days/weeks past the semester’s end will the course site remain available to students?” Additionally, decisions regarding whether individuals from outside the institution (mentors, guest discussants, consultants, etc.) will be able to view course sites and/or participate in discussions or chats should be covered, including who has the authority to approve special system accounts.
Site Management
Creating Course Sites. Here, the rst decision, on a procedural level, whether a course shell will be stablished for every course offered t the institution, whether a site was equested or not. The time savings f automatically “batch creating” ourse shells must be balanced gainst the server space taken up by tes that will remain unused the ntire semester. Additionally, if the ystem is configured to allow public rowsing, the institution’s image ay suffer if their catalog of online ourse sites resembles a virtual ghost own.
If course sites are not batch-cre-ted from the semester’s offerings, he next consideration is who is able or allowed) to create a site. Most MS packages enable system dministrators to determine whether aculty may create their own course hells, or whether sites will be built pon request. If they must be equested, who can request a site? Only faculty members? What about aching assistants or departmental upport staff?) If a site is requested, ow quickly will it be made avail-ble for faculty use?
Finally, once a site is created, polies related to the default configura-on of the empty shell may be elpful. For example, how will ourse sites be named and/or num-ered within the system? Some CMS dministrators utilize a course num-ering plan that enables them to earch within the system database by epartment, course number, section umber, semester offered, or home ampus, for example. Will there be reas within each site that remain ff-limits to public browsing? chool or departmental policies may fluence some of these decisions, hile others must be aligned with deral mandates related to copy-ght and privacy.
Maintaining Course Sites. This ategory is focused on the availabil-y of course sites. At semester’s end, will “old” course sites be allowed to remain on the server, and if so, for how long? Whose job is it to remove courses no longer in use? Will instructors have continuous access to all their course sites, including those built for courses they’re not currently teaching? These questions, and more, fall into the category of site maintenance, and the policies developed to answer them reflect our perceptions of instructor roles and responsibilities, as well as the reality of storage or server memory limitations.
Re-using Course Sites. If course sites are to be re-used (and this is one of the great advantages of having a CMS in the first place), determining how and when sites will be “recycled,” as well as by whom, will be helpful for faculty and staff to know. Who will prepare the Web pages for re-use? What is retained in each site when the recycling occurs? For example, will discussion postings be automatically saved when sites are copied, or must they be archived in order to avoid deletion? Must faculty indicate their desire to re-use course sites, or are they all recycled and kept on the server, regardless? Again, server limitations may govern many of these decisions.
Archiving Course Sites. It may be a good idea for an institution to keep one archival copy of each of a semester’s course sites in the CMS. This way, in the event of (for example) a grade challenge, the course site may be retrieved for review, even if the instructor has since left the institution. Policies related to the retrieval of archived sites (Who may request that a site be “brought back” and for what purposes?) may provide reassurance to faculty regarding the purpose of such archives and to avoid concerns related to intellectual property rights. Some institutions inform faculty of these policies by including them in a consent form that instructors are expected to sign prior to using the CMS.
Non-instructional Uses. The tools found in a CMS offer a variety of communication and content presentation options, so it’s not surprising that many users decide to build “course sites” for non-instructional purposes (student advising, research, committee work, etc.). While this can lead to a greater awareness of the CMS throughout the institution and facilitate user familiarity with the system, it can also lead to questions of how such sites are to be managed and supported. A clear policy on who may use the software, and for what purposes, may be helpful. For example, are student groups allowed to create sites? If so, must they have a faculty sponsor? At some institutions, those CMS users assigned the role of “instructor” may have access to student information that other students should not see (ID numbers, for example), so limiting the system roles users may have would be an appropriate security move.
Academic Concerns
Quality Standards. Academic freedom notwithstanding, an institution has the right to expect its faculty to prepare high quality instructional materials and utilize them in an organized fashion. Attempting to prescribe specific standards of quality in online course sites can be a minefield, however, and caution is recommended. Instructional support staff may instead prefer to suggest a variety of known “good practices” based on learning theory, educational research, and sound instructional design, if this area is to be included in a policy document.
Training. Will training or some form of system orientation be required of instructors prior to CMS use? While required training can be time-consuming to provide, it may save staff time on trouble calls later.
If multiple instructors use a single course site, are all of the instructors required to attend training? What about teaching assistants? What if the instructor has prior experience using this CMS at a different institution? Resistance to required training is a natural phenomenon, and carefully balancing the needs of instructors with the resources of the support teams can be a critical factor in the successful adoption of a CMS. Related questions of whose responsibility it is to offer training/ orientation activities and what such sessions will include may also be addressed in this section.
Compensation. If additional compensation for course development is available, this should be explained. Who is eligible for this compensation, how much is it, and what is expected of the faculty member who receives it? If the CMS is being used primarily for enhancement of face-to-face classes, extra compensation for online course development may not be available, although any options for institutional grants or special project funding may be appropriate in this section.
Technical Issues
Size Limitations. Technical constraints may require the establishment of size limits on course sites or on the size of individual files uploaded to the shell. These should be clearly stated, along with any exceptions to the policy. Information on software and support options for compressing files should also be provided for course developers.
Technical Support. When a user can’t log in to the system, when a gradebook isn’t displaying scores, when a file doesn’t upload correctly, who is available to help? Are there separate support units for truly “technical” problems (“The system doesn’t recognize my username!”) and what might be termed “usability problems” (“I can’t remember how to upload test questions into the pool.”)? Appropriate response-time goals (e.g., answering messages within one hour) may be included here, as well.
Authentication and System Integration. How will users be authenticated for access to the CMS? Will they enter through an institutional portal? Will users be limited to one account per person? As more institutions integrate their large-scale software systems, these issues become critical to information access and security. Schools opting for “single sign-on” run the risk that if a password is stolen, it provides access to everything; when each online system requires a different username and password, however, users have a tendency to write down—and lose— these codes. Issues related to system integration (library access, grade submission, course enrollment, etc.) are larger than a single software package and must be decided centrally, with input from representative constituencies. A CMS policy document should reference these policies and include links provided for those available online.
Auxiliary Software. Many special-use software packages are designed to run in conjunction with CMS systems, including software for online testing, browser “lock-down” software, and videoconferencing systems. While such programs can greatly expand the usability and effectiveness of the CMS, policies related to software evaluation and purchase recommendations, as well as installation and maintenance, can prevent many organizational headaches down the road.
Approvals and Distribution
As noted previously, the categories and topics suggested are a starting point for discussions of responsibility and authority, but are unlikely to be comprehensive and applicable to all institutions. Each institution must base policy decisions on factors specific to the student population, technology infrastructure, staff resources, and faculty needs. Once the policy document is drafted, careful review by administrators (including legal counsel), by users (teachers and students), and by support staff (technical and instructional) will help to avoid problems after the policies are implemented.
Once the policy document has been read and approved by the appropriate parties, the next question concerns its dissemination. Should the document be given to every faculty member? Should it simply be made available to anyone who’s interested? Keeping in mind that the policy manual is unlikely to ever truly be completed, but will evolve based on need, it may be appropriate to maintain it solely online. This way, the most recent version is always available and users will need to refer to the virtual copy, rather than a printed edition that may quickly become obsolete.
Summary
Policies—the philosophical and procedural bases for decision-making— exist whether they’re written down or not, but the process of articulating these ideas provides an agreed-upon framework for managing a complex system. The preceding discussion offers a simple structure or protocols regarding administra-on, site management, academic oncerns, and technical issues that an easily be expanded or modified s CMS usage grows or changes irection. Unfortunately, a long list f must-do activities can take prece-ence over creating a policy manual, ut the best time to develop policy is efore it’s needed. The hours spent ormulating a consistent set of uidelines for supporting, managing, nd maintaining a course manage-ent system will pay off with fair-ess, time savings, and increased rogram credibility.
About the author
