What Kinds of Issues Should Be Considered

At this point in the process, needs have been defined, existing resources have been inventoried, and, in some cases, a set of functional specifications describing what the technology solution should be able to do has been developed. In other words, a lot has been accomplished. The problem is, there still isn’t a new or upgraded system for users to appreciate. Teachers might soon be asking when they can get on the Internet, and principals will want to start using online applications to send reports to the central office. In any case, it’s natural that people want to know that plans are turning into results. Take heart. The initiative is on the right track. By taking time to become educated and informed, you improve your chances of avoiding "the big mistake" (i.e., you know, the one that costs someone a job—like spending large amounts of money to build an inappropriate or even useless technology solution). In addition to finding the best technology solution, the task at hand becomes preserving everyone’s patience and good will.

The results of the Needs Analysis, Functional Specifications, and Current Resource Inventory must now be reviewed together. The solution being sought during this phase is the one that most effectively fills the gap between what is needed from the technology system (e.g., the software needed to do the job and the hardware and networking needed to run it) and what is currently available. The solution will usually be a blend of the following three options:

• build a new system
• buy a new system
• augment and enhance an existing system

There are many things that must be considered before making a final decision or recommending a solution to the ultimate decision-maker. You know what is needed and what is available and, if you’ve followed earlier suggestions, you should have a sense of the possibilities technology can offer. Now it is time to weigh these possibilities against the organization’s capacity to handle them. There are many different labels and buzzwords used to describe these types of analyses—build versus buy analysis, feasibility study, alternatives analysis, etc. Rather than focusing on the jargon, keep in mind these basic questions that must be answered:

• What is the best approach to meeting your requirements (i.e., filling the identified gap)?
• How much is this solution going to cost?
• Will the benefit be worth the cost to the organization?

The first question embodies many more detailed ones (e.g., Should the organization build or buy? Should it upgrade or start over from scratch? Who will do the work? How long will it take?). Answering these questions should help planners determine the best technology solution. However, planners must establish priorities and consider the ultimate costs. Resources for paying for the solution must remain at the forefront of planning and the decision will have to be put into perspective as it relates to the goals of the organization.

Because this phase is so important, it may once again make sense to ask for help. A small advisory team could provide the needed assistance. You should have already identified technologically useful personnel within your organization. Likewise, by now you may have a shortlist of possible outside experts. The team might consist of:

• someone very familiar with the functional requirements and mission of your organization (perhaps a teacher, administrator, instructional supervisor, or division head)
• someone very familiar with current system capabilities (perhaps a technical support person)
• someone who has been through a system implementation process before, ideally within the organization (perhaps a seasoned staff member)

If the solution must meet the needs of several types of users, which is likely under most scenarios, it is best to include representatives from each of the identified subgroups. Depending on the size of the organization, it might also make sense to invite an outside consultant to more objectively facilitate this process.

Thinking through Options

In years past, many organizations and businesses chose to select a "custom-developed solution" because there were fewer options in the marketplace than there are today, and those that did exist were limited in scope. If an organization wanted a computer system to do something, it had to write a program or hire someone to write a program that would address the need. Similarly, if it wanted a specially configured machine, someone who could put it together had to be hired. Today, there is a much wider and richer commercial market of hardware and software products to meet the needs of education organizations. Still, it isn’t safe to assume there are products that will exactly meet any and all requirements. Planners should consider an array of possible approaches.

Chances are, most technology solutions will include a number of different products and applications. Some of these products might work together efficiently because they are part of a system or suite (such as Microsoft Office Suite, SmartSuite, or Corel Office) or because they have been specifically programmed to take advantage of a particular operating system. Often, however, choices must be made from several packages that do not relate to one another and may need to be customized to make them work well together. For instance, needs might necessitate the selection of a student information system package, a personnel information system package, andan accounting package from three different companies (not to mention desktop and laptop machines from different manufacturers). Sharing information between two or more of these packages might require special programming to create an interface (and incorporation of data standards to ensure interoperability). Similarly, exchanging data between computers with different operating systems might require special software, and perhaps hardware, as well. Figure 3.1 lists the key software design options that should be considered for each type of software application the organization requires.

Figure 3.2 illustrates the trade-off between the relative demands of staff effort and external effort depending on the type of software solution selected.

As can be seen in Figure 3.1 and 3.2, software solution options are listed in ascending order with respect to the cost the organization would incur for hiring outside expertise, and in descending order with respect to the amount of effort (cost) in-house staff would incur developing and implementing the system. Note, however, that the diagonal line doesn’t quite touch the corners of the rectangle because even custom development is likely to involve some additional costs above and beyond the cost of program development, such as having to purchase software development tools. On the other hand, completely outsourcing a function still requires some internal effort, if only to negotiate and administer the outsourcing contract. Figures 3.3 and 3.4 provide key questions to ask before and during the software reviewing process.

Some education organizations find that many of their technology needs can be handled by service bureaus or outsourcing agents. If it is determined that this is the best solution for the organization, don’t limit the scope of the search for these bureaus or agents to the commercial world. In many parts of the country, there are county and regional education agencies, college/university consortia, and state information management offices that offer technology services to individual institutions or school districts on a cost-recovery basis. Some states have well-developed cooperatives that provide information processing to education agencies.

There are several key questions to ask when looking for a service or product that will meet the needs of an organization. If a market survey is used to search for a software product, there are several published compendiums that you could consult, including those published by DataPro and Auerbach. There are also many sources available on the World Wide Web that can provide information about commercially available products and services.

Performing a Build-Versus-Buy Analysis

While customizing a current software product’s features to match an organization’s needs can increase the software’s usefulness, and may eliminate or postpone the need to replace it, the anticipated benefits must justify the costs of the modifications. On a cautionary note, be aware that customization of any commercial software product can create inconsistencies with the basic product—meaning that future releases or updates from the developer may not work with the customized edition. Similarly, modification may limit, or even invalidate, product support and warranties.

Note also that modifications that are intended to add or change a software product’s functionality are generally feasible. Modifications to improve the speed or other aspects of a product’s performance, or to enable it to run on different types of hardware, are usually not, and should not be attempted. Software compatibility and performance may reflect fundamental aspects of the product’s code (i.e., formulas for operation) that can be changed only with great difficulty and by persons with a thorough knowledge of the program and access to the source code.

Selecting Software for Classrooms

School districts should decide on specific sets of software that each classroom will have based on grade level and subjects taught. Using an economy of scale, a district can then negotiate "site licenses" with the software vendors in order to reduce costs. This approach may not be possible when different schools (or even different teachers) want different software packages.

Dealing with Hardware

Once these basic questions about software products have been answered, additional questions about hardware must be addressed. Some staff may use Windows operated computers, while others prefer Mac OS, UNIX, Linux or another platform. Unfortunately, networking different computer platforms is still a tricky endeavor, although it is possible when equipment isn’t too old and there is software available for use on both platforms. When resources permit, it may make sense to try to accommodate the platform wishes of all staff members by developing an integrated system that keeps everyone happy rather than declaring that everyone must use the same platform.

Purchasing versus Leasing

In comparing the relative advantages of purchasing and leasing equipment, the agency will need to weigh the total cost of ownership with total cost of use.

While leasing spreads the cost of equipment over time and facilitates frequent upgrades, those upgrades and deferred payments come at a price. Often the overall cost of a lease may cause the agency to pay the full price for two or three systems, but result in only one system in place at the end of the contract. Additionally, as discussed earlier, older equipment can sometimes be re-deployed to a function requiring less computing power and still be beneficial to the organization. Equipment under lease typically returns to the leasing company.

There are advantages to leasing, but they must be negotiated up-front. Primarily, with this arrangement maintenance can be built into the contract. Some vendors even offer classroom computers on a three-year lease with a one dollar ($1) purchase option at the end, thus allowing for later re-deployment of equipment. Leasing may also provide budgetary advantages for future planning. For example, a local education or post-secondary institution might find that upon completion of the lease, such an ongoing line-item in the budget is easily extended so that hardware and software resources can be continuously replaced as they age. Finally, when budgeting for an outright purchase the organization should build in for periodic replacements, thus over multiple years the cost differential may disappear.

Evaluating Human Resources

Once the desired technology solution has been identified, planners need to look at the organization’s human capacity for handling the implementation and support of the project. The choice is generally among:

• internal user staff
• internal technology or systems staff
• external technology/systems staff responsible for implementing technology (e.g., a state MIS department doing a project for a state education agency)
• external contractors or product vendors

Often a combination of several of these categories makes the most sense. Contracting for customizations or development makes sense when:

• personnel are not available, are inexperienced, or not trained for the task
• the cost for contracting is less than the equivalent cost of staff time
• the timeline for completion is short and the contractor can meet it more easily than staff

On the other hand, using internal staff makes sense when:

• the local staff is well trained and experienced for the task
• personnel fully understand the required solution and its functions
• personnel are available at the time of implementation, and their availability through the life expectancy of the software application is reasonably assured

The support of your new system is as important as its implementation. When discussing the maintenance of your technology, be very specific about your expectations. For example, can a district afford to have a payroll system down for 24 hours? Can a classroom teacher afford to have a school network down for 24 hours? And what will the penalty be if a vendor is unable to repair a computer, provide a substitute, or fix the system in a given period of time?

When staff members are evaluating the resources needed to implement and support hardware or software, the classroom environment must be considered. Since the most important activity of our "business" is the education of students, what happens when a prepared lesson is unavailable because the system is down? Are there staff at the school that can help the teacher? Can the vendor respond immediately?

Choosing and Preparing a Site

Big screen televisions are nice, but not when placed in small rooms. What if the TV needed to have major repairs done? Half of the furniture in the room would have to be removed just so the repairperson could access the console. A big part of putting a technology solution in place involves preparing the physical site (see Figure 3.5). The location selected must accommodate both the equipment and the people who will use it. Prerequisites include good ventilation and breathable air, comfortable temperature ranges, usable lighting, easy access, safe passage around wiring and equipment, and acceptable security mechanisms.

Making a Final Decision

How does the final decision get made? Unfortunately, there are no easy answers. Ultimately, decision-makers must weigh the pros and cons of the options generated by the Needs Assessment, Functional Specifications, Build Versus Buy Analysis, and Cost-Benefit Analysis. There are a few more steps you can take to help inform your decision as well…

Reviewing Organization Guidelines and Procedures

If the organization, or a peer organization, has already established a set of guidelines for selecting technology, now is the time to bring it back out. For instance, a school district or state education agency may have contracts with identified vendors with whom staff members are expected to work to purchase equipment. Or there may be other specific procurement procedures in place that must guide purchasing activities.

Seeking Outside Advice

If there is not sufficient in-house expertise to support an initiative, planners may want to hire an independent consultant or consulting firm to design specifications for the system. Subsequently, the contractors could then provide a bid on implementing the design as well. There are several advantages to dividing design and implementation into two phases. First, if design specifications are not satisfactory, planners can choose another contractor to redesign and implement the solution. Second, if planners approve of the work done during the first phase, there can be financial incentives to using the same group for implementation (i.e., a "multi-project" discount).

Another way to find out who is available to provide certain goods and/or services is to issue a Request for Information (RFI). An RFI can identify sources of assistance from outside the organization in two ways:

• use the RFI to select a specific desired vendor of a product or services
• use the RFI to specify what the system is expected to do (i.e., the essence of the Needs Assessment, Product Inventories and Functional Specifications documents) and then permit bidders to propose products, custom developed systems, outsourcing contracts, etc., as long as they confirm that their solutions are cost-effective ways of meeting the identified needs

Reviewing References

Have you ever been to a restaurant and thought that something looked appealing, but you just weren’t sure, so you waited until someone else tried it first? The same principle can apply to selecting technology solutions. If you know a peer organization implemented and used the technology that your organization is considering, ask for input to help inform your decision-making. Talking to users should occur early in your deliberations because you want to learn key information about the system or software before making your decision. There are certain questions you should ask to help compare use with your own organization’s needs. If you choose to work with a vendor that is unfamiliar to you, you will want to ask the same questions to several of the vendor’s references (see Figure 3.8).

Analyzing Costs and Establishing a Budget

Throughout this decision-making process, you’ve probably amassed a great deal of information that relates to the approximate costs of an appropriate technology solution. It’s now time to develop some more precise estimates.

When establishing a budget for the purchase, watch for hidden costs. Don’t let "unanticipated costs" push the project over budget. Plan for the worst scenario and, relatively speaking, the results will likely look pretty good (as opposed to the other way around). The budget should contain adequate funds to support key tasks for the level of implementation envisioned. The initial purchase price is typically only a fraction of the full cost to implement and operate a system. In addition, how funds are acquired (e.g., bonds, maintenance and operational funds, donations, etc.) and applied (purchase, lease, lease/purchase) has an impact on acquisition costs. There are several key elements of anticipated costs to consider. Some are presented in Table 3.1.

Again, resist the temptation to think short-term. The annual maintenance and operations budget may be appropriate for most of the budgeting categories listed in Table 3.1, but hardware purchases and facility acquisition may require longer-term capital financing, which often is budgeted separately. When considering costs of a new or upgraded system, remember to think in terms of the long-term investment. Life-cycle costs, which include expenses to support and maintain a system over its expected life span, are far more important, useful, and realistic for planning than simple implementation costs. Consider a reserve of funds (contingency money) for unforeseen changes during the course of the initiative. If you allocate your entire budget at the start, you may find yourself without options due to a lack of financial resources later when you encounter problems.

Procuring Resources

In the 1990s, a rush to purchase hardware and software sometimes led to mistakes in technology choices. Since then, many school districts and state departments of education have developed a systematic approach to technology procurement. Education organizations often have a number of possible financing options, including some unique ones. School districts may be able to fund certain initiatives through bond sales. Universities may have endowment funds. Additional sources include grants, foundations, donations, and joint public/private ventures.

Any restrictions and/or conditions that govern financial resources must be identified to confirm that they don’t conflict with the organization’s objectives and strategic plans. Wherever the money comes from, the financing method should be appropriate for the expenditures. For example, issuing 15-year bonds to purchase hardware with a life expectancy of 3 to 5 years doesn’t make a lot of sense, unless there is a built-in plan to continue to make upgrades and purchases throughout the life of the bond.

Negotiating the Bid Process

Some people view a public bidding process as inefficient, time-consuming, and restrictive. However, there are several reasons why such a process should be employed during technology acquisitions:

• The process encourages open competition. Bidders may be unaware of the price being offered by their competitors, which increases the likelihood of receiving a good bargain.
• A properly administered public bidding process decreases the legitimacy of complaints from vendors and citizens that purchasing decisions were made through collusion, favoritism, or behind closed doors.
• The agency is able to request special combinations of products and individually designed services without having to pay for unwanted components that often come with package deals and off-the-shelf products.
• The process can provide an objective set of purchasing criteria that will assure the purchase supports the mission and operational needs as defined in the agency’s strategic and technology plans.
• Feedback from bidders may result in the early troubleshooting of unforeseen problems or conflicts in design.

Bid requests can fall into any of several categories. Technical specifications are most commonly used for the purchase of specific equipment. The specifications will set a minimum standard for components, service, warranty, and other agency needs. Well-written specifications can help to standardize the components on a network and assure the compatibility of products. Good specifications can also provide strong evidence of the agency’s position with regard to the scope and intent of the parties if a dispute were to arise between the agency and a vendor.

Most often, specifications will designate minimum standards for functionality and quality. Typically, they do not designate a particular brand and/or model. In some cases, the minimum standards may be set by referring to a specific model by using the phrase "or equal" which then permits vendors with alternative products to demonstrate that their proposal will result in functionality and quality equivalent to or better than the product specified.

A Request for Qualifications (RFQ) often is appropriate when the agency is purchasing services and does not yet have a specific vision for project goals and desired services. The RFQ is used when seeking specialists to help define and, perhaps, manage a project. Because the successful vendor will be assisting the agency in defining the project, it often leaves the question of pricing open to negotiation.

A typical accounting requirement is the use of a Request for Proposals (RFP). The purpose of an RFP is to request proposals from vendors that actually spell out specific details about each respondent’s plan, including proposed products, equipment, costs, delivery dates, etc. The organization may have a rule that contracts over a certain dollar amount must be awarded as a result of a competitive bid process. If so, there is no point narrowing a market search down to a single preferred product since the product’s vendor will eventually have to respond to an RFP anyway. Thus, planners can save time by simply defining the category of vendors/developers from which bids will be solicited, and then concentrate on writing a good RFP.

Of equal importance, be sure to involve the correct set of people in the procurement process. If state or local purchasing administrators or the management information systems (MIS) department needs to be included, delays are likely to result if planners wait too long before contacting these offices.

Although many organizations have a specific format that must be used for RFPs, it is important that planners be sure to include all of the information that will be needed to select a contractor from among the various bidders. Figure 3.9 contains a list of requirements that are often included in an RFP.

Before releasing an RFP (i.e., a bid request), the agency may want to consult with a business administrator, legal counsel, or other qualified individual to examine it and ensure proper compliance with district, local government, state, and federal regulations. Many agencies have procurement personnel or business officers who can review the process with them.

Listed below are some topics to consider when preparing a bid request. The organization should also consider having an external technology expert review the request and ensure that it covers all of the organization’s needs and, presumably, satisfies the need to ensure an objective process. Note that these guidelines are intended to provide a broad overview of preparing a variety of bid requests. Details of an actual request will depend upon the specific needs of the agency. Also, the request process may vary, based not on only the nature of the purchases, but also state and local laws and policies.

Basic Design Parameters:

• determine how the new or upgraded technology fits into the strategic plan of the agency
• set forth the basic structure of the project, including a description of all component parts

(Note that an effective needs assessment and technology plan should eliminate ongoing changes during the design and implementation phase, which will help control costs and speed the process for timely implementation.)

Contract Parameters:

• develop a statement of work that clearly defines roles, responsibilities, deliverables, timelines, and costs
• define whether the scope of the contract will be for design only, design and implementation only, or design, implementation, and support after deployment
• specify the level of support services expected after deployment—e.g., whether the vendor will manage the technology or simply provide troubleshooting and repair
• establish a clear price structure (and avoid allowing the contractor to price on a time and materials basis)
• define a payment schedule
• payment should be based on specific deliverables or benchmarks
• deliverables can be written into the RFP, but the language should allow for additional negotiation
• set reasonable timelines and benchmarks for development and completion
• ensure that the education agency will receive sufficient documentation to be able to use and maintain the technology after deployment
• determine how and when documentation will be delivered
• determine the form of the documentation (e.g., written guide, online guide, etc.)

Vendor/Contractor Qualifications:

• define the training and expertise required of vendor/contractor respondents
• require evidence of company stability (e.g., financial reports and history)
• require references from other clients (preferably peer organizations) serviced by the vendor
• require the contractor to document qualifications of the individual staff who will work on the project
• require the contractor to present a proposal based on your organization’s needs assessment and technology plan

Legal Issues:

• Establish ownership of source code or the computer program(s) used during development (especially of software applications). The ownership of source code is critical because the agency may later decide to change vendors or bring maintenance of the project in house. (Note that for any development supported partially or completely by federal funds, the code automatically becomes part of the public domain. Inform vendors of this stipulation up front to avoid misunderstandings and/or future legal conflicts.)

• Ensure compliance with copyright laws and provide indemnification for the education agency for any copyright violations made by the vendor.

Comparing Costs to Benefits

Proposals submitted by vendors and contractors in response to an RFP should include detailed information about project costs, both on a total and component-by-component basis. Once these costs are known, planners are no longer functioning in the world of estimates and conjecture. The next step is to compare these costs to the anticipated benefits of the project so that the potential payback can be estimated.

Putting a dollar amount on "benefits" is the most difficult aspect of this analysis. While technology systems seldom reduce an organization’s cash outlays, they may reduce staff time previously spent on unproductive tasks (a value that can be estimated) or provide additional time for more important tasks, such as instruction. Because of the increased efficiency of an organization, there may be a dramatic improvement in staff morale by allowing staff members to do what they were trained to do (e.g., teaching students or analyzing information, rather than transcribing information or verifying data on forms).

Remember, a key reason for acquiring the new technology is to support student learning. Providing an enriched education environment for students cannot always be easily measured in dollars and cents, and defining the cost-benefit ratio of instructional technology acquisitions can be difficult. Education organizations do not routinely look at "Return On Investment" (ROI) to justify purchases and programs, as do private sector companies because a standard methodology for determining benefits may simply not be available.

As discussed in Part 2, another benefit to acquiring a new technology system is that maintenance costs are often lower than those for the technology being replaced. Converting from existing systems to new ones may provide an opportunity to roll current costs for maintenance and support into purchases of hardware and software with warranty periods and lower future maintenance and support charges. Thus, funding plans can be augmented through reductions in current maintenance costs that offset purchase costs. Some organizations have found that by replacing old telephone systems with new ones that provide better service and connectivity, they reduce their annual phone bills, and receive more capacity and expanded capabilities (such as putting a telephone line into each teacher’s room). When technology to perform a service, such as student registration, replaces a service that is currently being outsourced or done manually, the ROI may also be reached in a much shorter time.

Documenting the Decision

It’s now time to document the recommended technology solution that has emerged as a result of this analysis. The purpose of formal documentation is to present key decision-makers in the organization with enough information to approve, modify, or reject the recommendations. (Of course, if you feel that the likely outcome is rejection, then you are better served by developing a stronger case before presenting it.) Even if the decision-making process is informal, or if very few people are involved, it is still a worthwhile exercise to document the plan as a check of its viability and comprehensiveness. If planners can’t articulate the rationale for their decision, they may be missing key elements.

A business case is the most useful format in which to prepare such documentation. It not only includes a description of the recommended solution, but also documents the anticipated costs and benefits. In short, it should give key decision makers all the information they need to make an informed decision. See Figure 3.10 for a suggested table of contents in a Business Case document.