Skip Navigation
Forum Unified Education Technology Suite
  Home:  Acknowledgments and Introduction
  Part 1:  Planning Your Technology Initiatives
  Part 2:  Determining Your Technology Needs
  Part 3:  Selecting Your Technology Solutions
  Part 4:  Implementing Your Technology
  Part 5:  Safeguarding Your Technology
  Part 6:  Maintaining and Supporting Your Technology
  Part 7:  Training for Your Technology
  Part 8:  Integrating Your Technology
  Appendix A: Sample
Acceptable Use
Agreements and Policies
  Appendix B: FERPA Fact Sheet
  Appendix C: Web Guidelines
  Appendix D: Sample Security Agreements
  List of Tables and Figures
    Powerpoint Overview (700KB)
NCES Webmaster
Part 6: Maintaining and Supporting Your Technology

Introduction to Maintaining and Supporting Technology in Education Organizations

At some point (after a great deal of planning and even more hard work), the new computer technology will be up and running-the prospect of which sounds good, but can be anticlimactic. Is life in the organization perfect now? Probably not. Is it better than it was before? Probably so. But for this to be true, the technology has to be used, maintained, and supported properly. This includes all equipment, software, and network connections. Moreover, ongoing training and support must be provided to all user groups. Once these activities have been instituted, it is more likely there will be a dramatic difference in the way the organization operates.

Overseeing Technology

Several groups of individuals probably contributed both energy and expertise throughout the process of implementing the new or upgraded technology system. By now, it should be clear which people in the organization have the most interest in, enthusiasm for, and knowledge about technology. These are key people to help keep the system running smoothly after implementation has been completed. and they are prime candidates to serve on the Technology Oversight Committee.

A Technology Oversight Committee should be appointed to oversee system use,
maintenance, and ongoing improvement.

The Technology Oversight Committee should be a mix of users and technical staff who can help keep the system running efficiently and effectively. At least some of the people who served on the Project Team and the Steering Committee should be included on the Technology Oversight Committee, as should representatives from the organization's technical staff, training staff, current users, and potential users. In order to accommodate multiple voices, plan to rotate committee members on a regular basis (i.e., one-fourth of the committee turns over annually). There is no perfect schedule for committee turnover-just make sure that you don't find yourself with only inexperienced and unhappy non-users on your committee.

Depending on the nature of the organization, there may be several oversight committees. For example, if the organization is a school district, it may make sense to have a committee at each school (e.g., an Instructional Technology Committee) as well as a district-wide committee that includes representatives from all schools. Meetings should be scheduled regularly, but the group shouldn't convene unless it has real work to do. Like you, committee members are busy people. Don't expect to maintain their interest if there aren't meaningful agendas for their meetings.

Considering Maintenance Services

When discussing the maintenance of the physical aspects of the technology throughout its life span (generally 3-5 years for most equipment and applications), it makes sense to think seriously about what maintenance requirements actually entail. The term "maintenance" refers to those preventive, diagnostic, updating, replacement, and repair procedures that an organization undertakes to keep its technology working effectively and efficiently. Maintenance can be provided either by persons who are employees of the organization or through outside contractors. Maintenance items might include:

  • replacing wear-and-tear parts and consumable supplies
  • repairing or replacing faulty components
  • cleaning equipment
  • monitoring the condition and functionality of networks and equipment, including testing website access and links
  • redeploying equipment
  • updating or upgrading hardware and software, including installing new versions of the operating system
  • adding or deleting users from a system, or modifying user rights and properties
  • backing up stored files
  • documenting trends and patterns in the use of applications or equipment
  • removing and disposing of equipment and applications

When the network goes down in a school or district, the administrators, teachers, and students sometimes have to wait for hours (or even days) until it comes back up. Lost information and data may not be restorable. This type of outage in the business world can cost tens or hundreds of thousands of dollars in costs or lost sales, but lost instructional time has not yet been valued in the same way. However, as schools rely more on the use of technology both administratively and instructionally, the loss of time and information is increasingly understood to be expensive and disruptive to the learning process.

Possible Indicators for Assessing Technology Maintenance

  1. Are equipment and infrastructure reliable?
    1. How many maintenance incidents were there per workstation/server during the current academic year (by cause, category, and location)?
    2. What was the average number of downtime hours per workstation/server during the current academic year?
    3. What is the average number of calls to help desk/tech-support services per workstation/server?
    4. What is the average elapsed time between the receipt of a call to the help desk and the response call to the end user?
    5. What is the average elapsed time between the initial response call and the notification of problem resolution?
  2. Are appropriate preventive maintenance procedures in place?
    1. Has a preventive maintenance schedule been established?
    2. Has a preventive maintenance checklist been provided to all end-users?
    3. Has access to frequently asked questions (FAQs) been provided to support staff and end users alike?
    4. Has access to user manuals been provided to end users?
    5. Are file backup procedures in place?
    6. Are disaster recovery procedures in place?
  3. Are update and replacement procedures in place?
    1. Has a replacement/upgrade schedule been established for hardware?
    2. Has a replacement/upgrade schedule been established for software?
  4. Are diagnostic and repair resources available?
    1. Is help desk support software available (e.g., trouble ticketing, resolution tracking)?
    2. Is diagnostic software available (as appropriate)?
    3. Are appropriate repair instruments/tools available on school premises?
    4. Are basic replacement parts in stock?

Establishing Maintenance Plans

Automoblie manufacturers recommend having an engine tuned and oil changed regularly to keep a car running as efficiently as possible. Similar maintenance is required of a computer system. It is best not to wait until problems arise-avoid problems in the first place! An organization can carry out much of its own routine, preventive maintenance (e.g., checking database size, purging outdated records, and deleting idle user accounts), but in spite of efforts to deliver a high-quality preventive maintenance program, problems will still occur. To deal with them, many organizations have maintenance agreements with outside contractors for fix-it-when-it-breaks service, particularly for hardware. The key factors in these agreements are response time to a trouble call and the availability and proximity of spare parts. In other words, planners need to know how long it will take to get the problems fixed when (not if) they arise.

One of the most feared expressions in modern times is "The computer is down."

--Norman Augustine

Maintenance agreements are like insurance policies. One needs to weigh the relative and absolute risks to the organization before making an informed decision about buying into an agreement. Some useful questions to ask before signing a maintenance agreement with an outside vendor can be found in Figure 6.1.

As an alternative to a maintenance agreement with an external provider, an organization can weigh the risks and benefits of in-house maintenance, assuming that expertise is available on site. Paying for time and materials only as repairs are needed (as opposed to a monthly fee) can save money. In other cases, the staff time necessary to complete repairs may make the in-house solution more expensive than it first appears. Losing access to critical systems can be even more "expensive" in non-financial terms. It is obvious that a payroll system cannot be down for long. It's also obvious that a lost server at a school site can be disruptive to the educational program and demoralizing to teachers learning to use a technology-enhanced classroom. Thus, it is imperative that a cost-benefit analysis be performed before deciding whether to pay a vendor to provide maintenance service (see Figure 6.2).

Maintaining Software

If the organization's computer system includes a commercial software package, it will probably come with a maintenance agreement from the product's vendor. Product maintenance agreements should be negotiated at the time of initial purchase or at the time that the software application is being developed. Such agreements usually are scheduled to "begin" either when the software is purchased or when the system is initiated, as long as the vendor continues to receive the stipulated monthly or annual maintenance fee. In return for this fee, the client organization typically receives application changes, additions, fixes (e.g., to errors), and other basic support. Maintenance agreements can also provide for copies of new releases (upgrades) at no or at reduced cost.

Upgrading Software

When dealing with commercial software packages, vendors typically offer a stream of new releases of their product on a semi-regular cycle. "New" releases are more recent versions of a software application that the developer has published, either to enhance features and functions or to correct problems in an earlier release.

If the organization has been keeping up with its maintenance payments, it has the right to receive to new releases when they become available. However, this does not necessarily mean that it must, or even should, upgrade to new releases. Weighing this decision can be tricky and requires the consideration of several factors. One thing to keep in mind is that upgrades should be assessed relative to the organization's current system architecture, network architecture, and other relevant guidelines. For an upgrade to be desirable, it must be consistent with established standards and contribute toward the organization's overall vision for technology.

If an upgrade does pass the first test (i.e., it meets established standards), it still needs to be approached with caution. Too often, the definition of an "upgrade" is simply a piece of software that has had its old bugs removed and new ones put in their place. Yes, unfortunately, new software sometimes gets distributed before all of its problems are resolved. When that is the case, those who have chosen to use the new release may become unwilling participants in the debugging process.

Another consideration when assessing the usability of software upgrades is whether the new release will require changes to other elements in the organization's technology environment, such as the operating system, hardware, or network software. Also, if major changes are included, the new release may be published as a new "version" or "edition" (rather than a release), which may require a new purchase as well. above and beyond the organization's current maintenance payments and/or budget.

Some organizations adopt a philosophy that they will never be the first to install a new version of a software application. Others tend to stay one release behind the "leading" (or "bleeding") edge to avoid such risk. Generally, these formal rules lower risk but may also delay appreciation of those benefits provided by a useful upgrade.

To decide whether or not to upgrade, the Technology Oversight Committee needs to evaluate whether the changes in the software provide more potential benefits than risks. Benefits should be assessed based on:

  • impact on user productivity
  • ongoing costs/savings
  • addition of useful functions
  • addition of useful content

Risks and costs should be based on:

  • costs for potential temporary loss of productivity
  • costs for retraining
  • new hardware, operating systems, or networks required by the upgrades

Replacing and Re-deploying Equipment

In addition to upgrading application software, upgrading hardware platforms on which the applications run is also a key part of system maintenance. Computer hardware follows a life cycle that is perhaps best described as "rapid, planned obsolescence" which refers to the fact that hardware will be overtaken within three years by new models that are better, faster, and (adding insult to injury) cheaper than existing models. This is especially true of desktop and laptop computers, although it applies to printers, servers, modems, and other peripherals as well.

Some very old Pentium machines may not do much but teach kids keyboarding skills. However, they still work. Moreover, when one breaks, it can be used for parts and help keep other machines running beyond their original life expectancy.

There is no way to buck this trend. It simply has to be recognized and accounted for in long-term technology plans. Ideally, the organization should develop its vision for system architecture (the design and contents of its computer system) to help determine when equipment should be upgraded or replaced and what type of new equipment or modifications to existing equipment will be needed.

A reasonable rule of thumb is to set a budget to upgrade or replace one third of the computers each year so that nothing more than three years old remains on site in the organization. It may be painful to see "perfectly good" machines withdrawn from use after such a short period of time, but the pace of change in the computer field is so rapid that three year-old machines are unlikely to be doing their jobs efficiently. Another solution is to lease the computers for three years. At the end of that time, either return the computers or lease new ones—in either case the organization should never be paying for old machines.

Once a decision is made to replace a group of machines, the next decision is what to do with the old equipment. Education organizations are typically multi-faceted, and there may be several potential homes for "once-removed" machines within your organization. A common strategy is to move machines from a student lab to an administrative office or vice versa. Internal redeployment, however, is not as simple as it sounds. The disruption caused by "trickle down" internal redeployment might actually exceed the cost of external replacement with new machines. Does it really make sense to maintain and support three generations worth of computer equipment? Some organizations establish clear policies that, while perhaps somewhat arbitrary, provide rules for equipment disposal. For instance, one university has decided that it will move equipment only once internally. The old equipment is then permanently disposed of by selling it to staff or students or by donating it to other organizations. Figure 6.3 lists issues that should be considered prior to making decisions about re-deployment.

Regardless of the plan for discarding old computers (be it internal re-deployment, external re-deployment, storage, or even disposal), all files from old machines must be deleted. To be confident of effective file removal, each hard disk should be erased completely, a process referred to as "degaussing" by technical experts. Saving time by not fully erasing files is never worth the risk of accidentally passing along information that shouldn't be shared. After all, think of the possible repercussions should the organization mistakenly divulge individual student data, sensitive financial records, or other private files.

Considering Support Services

As opposed to "maintenance", the term "support" refers to actions taken on behalf of users rather than those taken on equipment and systems. Support denotes activities that keep users working or help users improve the ways they work. Included under support might be such items as:

  • providing "Help Desks" and other mechanisms for resolving problems and offering guidance (e.g., automated information systems and searchable frequently-asked-question (FAQ) databases)
  • offering initial and ongoing training on equipment and software
  • identifying external resources, including websites, consultants, and volunteers as appropriate
  • integrating instruction and technology, usually through observation and personal interaction between a teacher and a technology coordinator
  • integrating administration and technology, usually conducted through specialized consultants or software/systems vendors

As with maintenance, support can be delivered through a variety of mechanisms, including in-house technology specialists, external volunteers, and outsourced contracts.

Professional development and training are addressed in Part 7: Training for Your Technology. Technology integration is addressed in Part 8: Integrating Your Technology.

It is critical to determine the type of support and training the organization will need. Trial and error can be a frustrating, costly, and risky way to learn how to use computer applications. It is essential to have planned activities to help and support users when new technology is implemented.

Support services, training, and certification must be ongoing to ensure successful post-implementation use of technology. As time passes, personnel, organizational needs, and the ways in which the technology is being used all change. Any and all of these changes must be taken into account when planning for ongoing system support.

E-mail from a troubled user: "Canyoufixmyspacebar?"

Possible Indicators for Assessing Technology Support

  1. Is technical support staffed adequately?
    1. What is the number of dedicated persons assigned to technical support (at building and organization-wide levels)?
    2. What is the percent of FTE hours assigned to technical support at building organization-wide levels? By primary area of responsibility?
  2. What is the technical support workload?
    1. What is the number of calls handled per FTE position?
    2. What is the ratio of calls or incidents to FTE support staff hours?
    3. What is the ratio of technical support staff to the numbers of workstations/servers?
    4. What is the ratio of technical support staff to end users?

Establishing a Help Desk

The most common way of providing user support is to create and staff a bank of telephones (or at least one phone) or e-mail accounts with people who are capable of patiently and constructively answering user questions. In large organizations such as universities, Help Desks may be available 24 hours a day. For most education organizations, however, it should be sufficient to have someone running the Help Desk for only part of the day, with the number of hours based on how many users there are and how many questions are being asked. It may even be sufficient to have someone check voice mail or e-mail twice a day to see if any questions have been forwarded.

Four Ways to Ensure Quality Tech Support in Schools (by Richard M. Beattie)

As school technology systems get more complex, schools must further professionalize their technical support departments. No longer can schools rely upon members of their academic departments who have an interest in technology to perform major system upgrades, maintenance, and troubleshooting. Anecdotal evidence shows a rising level of burnout on the part of those educators who have added the informal title of "computer expert" to their list of responsibilities within schools.

Unfortunately, schools have a long way to go. As a point of comparison, large companies strive to have at least one professional computer support person for every fifty computers (laptops or PCs) in use. Few, if any, schools enjoy a ratio this low. With the demands for hiring additional instructional staff in most school systems, it's no surprise that administrators can't focus on improving tech support departments.

Nevertheless, for technology to reach its potential in K-12 education, technology experts-not just technophiles-must be intimately involved in ensuring that a school's precious technology dollars are used to serve the school's mission and its unique student body. Achieving these goals starts with a firm commitment to quality in technical staff. This can be achieved in four ways:

  1. Administrators should recognize that technology experts must be able to focus on their roles on a full-time basis.
  2. Technical support staff must have an understanding of the educational process in addition to computer technology.
  3. Schools and districts must budget realistically not only to purchase technology, but also to maintain and upgrade it on a regular basis so that it can be used by students and teachers.
  4. Technical staff must be committed to making themselves key members of the school's planning process, not just crisis managers who keep the machines running.
Reprinted with permission from Electronic School, Copyright © 2001 All Rights Reserved.

When staffing a Help Desk, keep in mind that the person or people who work at a Help Desk must be detail oriented and able to demonstrate extreme empathy and patience. Each caller's problem must be treated diligently, even if it's the ninth (or ninetieth) time the same question or problem has been reported. Some schools use students to run the Help Desk. If a school district decides to use students to staff a Help Desk, it should assign a staff member to train, supervise, and evaluate the service provided by the students. Also, the organization must be careful not to ask students to help with sensitive equipment or files (e.g., grade reports of their peers).

In addition to solving user problems on a day-to-day basis, a Help Desk can also be valuable as a mechanism for documenting trends and patterns regarding the use of an application or equipment. Thus, it is important to track Help calls and responses. One effective way of doing so is by using a software package that generates reports like "most frequent queries" or "call distributions" (i.e., the distribution of callers who have the same problem). This information can be used when developing new training materials or tailoring future training to better meet user needs. Many users will find it helpful if frequently asked questions (FAQs) and their answers are printed in a newsletter or made available via the network.

Developing and Maintaining an Acceptable Use Policy

The development of an Acceptable Use Policy (AUP) is a critical component of technology planning. An AUP is important for all system users, including administrators, teaching staff, other staff, students, parents, the community, and any other persons who will have access to the system and its contents. Once developed, the AUP should be reviewed periodically by the Technology Oversight Committee, the Instructional Technology Committee, and other bodies responsible for oversight. The AUP should address the following areas:

  • individual rights concerning access to the system
  • individual responsibilities with regard to the system, its contents, and any connections established through the system
  • organizational rights relating to system oversight and monitoring
  • organizational responsibilities with regard to the system, its contents, and any connections established through the system

Protecting the privacy of sensitive information maintained within the system is essential. Security and ethical standards also remain important as long as the system is in operation. Both legal and technical staff should review the Acceptable Use Policy to ensure that appropriate protections are in place.

Monitoring Regular Use of the System

Another aspect of supporting computer technology is keeping track of how, how much, and by whom the technology is being used. For instance, if a school has a goal to increase technology use in the classroom, it is important to review the amount of time students are using the technology and what applications they are using, as well as routine teacher usage patterns.

Regular tracking of how, how much, and by whom technology is used can provide input into training, maintenance, and long-term planning.

Most commercial software packages and well-designed custom computer systems have built-in utility programs to collect usage information and turn out "canned" reports on use patterns and volume. Every system should have a staff member assigned to review these reports on a regular basis. Some commonly accepted indicators of usage to watch for include:

  • volume of transactions processed
  • number and average duration of user sessions
  • database size (if relevant)
  • volume of reports generated
  • downtime

In addition to these routine indicators, exception reports should highlight unusual usage patterns and/or any problems that occur (e.g., disk space constraints, database corruption, and interface problems with other systems). The more serious of these should not wait until the regular cycle to be reported-they should be addressed immediately so that no information is lost or damaged.

Assessing Ongoing User Needs

It may take a while before a new computer system is up and running at its maximum effectiveness. A key maintenance function that can be addressed immediately, however, is the development of a mechanism for collecting user suggestions (and complaints) about the system. Having a process in place for collecting this type of information provides a measure of control for an organization. It allows the organization to identify and document user problems, and helps with decisions about priorities for future investments. Without such a process, requests for change can build up without administrators realizing that problems are occurring.

To help set up a process for determining needed changes, consider using the following procedures:

  • develop paper or electronic forms for documenting requests and select a central point for gathering the requests
  • have the technology coordinator (or someone else) document and research the requests and develop a list of possible solutions
  • maintain a log that shows the date of each request, the source of the request, projected cost and time estimates, who needs to respond to the request, the date(s) of all responses, their priority, and disposition
  • review and prioritize the requests and possible solutions in keeping with the organization's system architecture, technology goals, and long-range plans
  • respond to all suggestions-if nothing else, simply acknowledge receipt of the comment

Make sure that all users understand the feedback process and that they feel free to use it. Where suggested changes are involved, the user bears the responsibility of distinguishing between needed changes and "nice to have" wish lists. Where new purchases are requested, the user making the request should provide any additional information that might contribute to the decision-making process.

Accepting (and Refusing) Donations

When companies replace their computer systems, they sometimes look to donate the equipment and/or software to education organizations. It is tempting to say "yes" to anyone offering something for free. On the other hand, a rule one might want to live by is: "Don't accept a gift you have to feed." If your organization is confronted with this situation, weigh both the potential benefits and consequences of every donation. Obviously, the organization benefits most from donated equipment that fits its long-term plan for purchasing and replacing equipment. Thus, when the organization is offered donations refer to an established plans and protocol that dictate whether or not they should be accepted:

  • Staff should screen potential donations to ensure compliance with standards adopted by the organization. Donations can be useful to supplement available funds and equipment. However, to avoid invalidating warranties and increasing future expenses for maintenance and support, all donations should comply with the same standards that would have been followed had the institution purchased the goods and services.
  • Just as with purchases, donations come with associated costs for installation, training, maintenance, power supplies, facilities, associated hardware or software, human resources, etc. (For example, most donations come without an operating system, which leads to the question of who will purchase the Windows or Mac OS?) In cases where donations are not in compliance with established standards, the donor might be asked to underwrite the additional maintenance and support that the donation will require.

See Figure 6.4 for additional considerations affecting the acceptance or rejection of donated resources.

Utilizing Volunteers

Since the E-Rate program enables schools and districts to "wire" buildings at a greatly reduced cost, reliance upon volunteer efforts may be less necessary than it once was. In any case, before making arrangements for a volunteer to work on an education organization's technology, check with insurance providers and other supervisory groups (e.g., the school district office) to determine whether there are limitations to what types of tasks a volunteer can perform. Consider that regardless of who performs the task, all work must adhere to relevant building codes. Additionally, non-trivial issues such as asbestos and lead paint may be relevant. Thus, onsite work can be a difficult issue that could create physical danger to students, volunteers, and others. It must be handled with considerable forethought. and perhaps most safely by trained professionals. See Figure 6.5 for additional considerations affecting the use of volunteers.

Volunteers can provide valuable services to organizations if they have relevant experience and are willing to work within the organization's plans.

Finding Qualified Help

This document has focused on finding the right people with the right expertise to help decision-makers. It has also acknowledged the necessity of having experts help install, implement, monitor, and evaluate the system, and the importance of providing ongoing technical support and staff training. But it has not discussed how to find these experts. There are numerous sources of qualified help available. Some might include:

  • professional organizations that provide relevant member services
  • private or not-for-profit consulting organizations or individuals
  • governmental agencies chartered to provide assistance
  • technical and professional publications
  • training programs
  • university faculty or centers
  • vendors who are willing to describe their solutions

Planners could also look for help in other organizations, such as peer districts within the state. Talk to their decision-makers. Ask about the consultants they used, and use this information to make better informed decisions. See Figure 6.6 for additional considerations when trying to identify qualified help.

When dealing with consultants and organizations that have products to sell or who represent specific products, make sure they disclose these relationships up front in order to avoid possible conflicts of interest. The organization should determine in advance whether vendors, organizations, and individuals who represent products would be appropriate sources of assistance. If a product recommendation is not a part of the help requested, or if an open and public bidding process will follow, vendors representing specific products may be able to provide current and appropriate expertise.

Previous Page -- Part 5 continued Next Page -- Part 7