In general, service owners just want the system that meets their needs. Discussions with IT about integration with existing systems on campus, support costs for the new implementation, and total cost of ownership frequently become adversarial. Simmons College reframed these issues in terms of goals common to the service owners and the central IT organization.
The Problem and Steps to Address It
Simmons is a small college in Boston with an enrollment of approximately 1,900 undergraduate and 2,800 graduate students. Both the administration and the purchasing of IT systems are centralized in a department called, simply, Technology.
The whole campus community benefits from the integration of systems, single sign-on, and coherent interface design. Different units within the institution, however, want to implement the best service solutions for their customers and for their own work. The way a new service fits into an overall institutional architecture is at best a secondary consideration. The result was a hotchpotch of disparate and independent systems. Technology, as the champion of coherence in planning of services, was often seen as a roadblock to departments' "getting the job done." So Technology found itself on the horns of a dilemma—be seen as an impediment to bypass, or become complicit in chaos.
In a coordinated approach to the problems associated with multiple systems that as a whole represent "the enterprise," Simmons has taken five policy steps:
This approach moves the dynamic from an adversarial view of central IT's role in system implementation to a perception of collaboration toward a common goal. At the same time, the process becomes transparent, and Technology's efforts to address system shortcomings and anticipate problems contribute to an impression of a helpful, flexible organization.
Technology Systems and Services Committee
For many years the college has had an oversight committee of the Board of Trustees along with the Technology Governance Committee to advise the senior vice president of administration and planning (to whom Technology reports). The advisory Technology Governance Committee includes faculty members, deans, and administrators.
The advisory committee had an Academic Technology Subcommittee to represent faculty technology interests, but which projects were funded and pursued remained opaque to units dependent on administrative systems. Moreover, senior administrative staff throughout the institution felt they had no voice in technology decisions or in the setting of technology policies and priorities.
Formation of the TSS, another subcommittee of the advisory committee, specifically addressed issues involving electronic processes on campus. The TSS
- provides a voice at the technology table for those responsible for administrative processes;
- introduces a degree of transparency into decision making;
- creates a forum for discussion among those responsible for different administrative functions;
- encourages cooperation between process owners; and
- enables the institution to take a holistic view of processes, rather than the narrower perspective of administrative units.
Empowering the TSS to make college-wide recommendations has brought together Technology, system owners, service providers, and consumers for a novel range of discussions. The TSS consists of representatives from the departments of Advancement, Finance, Registrar's Office, Student Life, Technology, and academic administration, including deans' offices and faculty. The committee has started to tackle data ownership issues, prioritization of administrative systems projects and enhancements, and communicating to the community about the availability of online services.
The TSS will soon address other difficult issues, such as security policies. The greatest challenge and opportunity is to ensure that decisions are made on the basis of transparent and comprehensible principles that can be consistently applied.
Technology System Assessment Protocol
In fall 2007, the TSS developed, and the Technology Governance Committee approved, the Technology System Assessment Protocol. Importantly, the protocol is owned not by central IT but by the institution through its representative governance structure. This changes the dynamic from Technology-imposed regulation and barriers to a joint exploration of the implications of implementing a service.
The protocol is designed to help the service owner and Technology better understand the total cost of ownership of a system before purchase. The Technology System Assessment Protocol is used when evaluating the addition of a new system into the enterprise, a new server-based application, or even the addition of desktop software, as it, too, may include unforeseen consequences. The TSS prepared this protocol to help faculty and staff with the preliminary stages of a technology project by making explicit the requirements, costs, and benefits of such a system.
On the academic side, projects to which the protocol would apply involve the implementation of discipline-specific technologies, such as an academic application in any field, a "tool of the trade," or a simulation (for example, bibliographic software, scientific equipment that captures data electronically, or a marketing strategy simulation). On the administrative side, projects to which the protocol would apply include information systems or applications to provide a service. They range from core financial operations to business affairs operations, admissions, student services (housing, registration, advising), and library services.
The Technology System Assessment Protocol prompts faculty and staff, in consultation with Technology, to think through both the plus and debit sides of the ledger—the needs, benefits, and opportunities that the specific system will address versus the costs, responsibilities, and technical requirements—prior to moving forward with the technology purchase. All IT purchases at Simmons must be approved by the central IT organization, and the protocol is a required part of the process. The protocol states it "will help support your business case," thus explicitly positioning this policy as helpful despite the hindrance implicit in the effort required to thoughtfully follow it.
The protocol begins by suggesting that people ask themselves whether they are:
- Thinking about implementing a new information system to provide new services or improve processes within their office.
- Interested in enhancing how data are accessed and/or collected.
- About to purchase software that will be accessed by multiple people.
- Interested in developing or purchasing an application for research or teaching that will run from different computers.
- Trying to implement a product to keep track of academic information.
If a department can answer yes to any of these questions, the interested parties are asked to read through the protocol and, if they decide to move forward, to work their way through the protocol with Technology.
Typically, a faculty member or service owner will believe his or her application is straightforward and does not require the protocol. Because the protocol is embedded in Simmons purchasing policy and process, it leads people to consult Technology earlier in their planning than in the past.
The rubric is as complete as we could make it, but certainly some ambiguity exists at the boundaries between the different areas of focus. The first distinction is among the technical, personnel, and financial loci of concern—not that any particular issue fits entirely or neatly under one of these three concerns! For example, technical concerns (hardware, software, programming) cost money and require consultants or employees to write programs, so technical concerns can also have consequences for personnel and finances. And personnel, whether consultant, contracted, or employed, also need to be paid. Nonetheless, it helps to focus attention on these three categories in exploring a new technology and asking the vendor the right questions.
The Technology System Assessment Protocol can be visualized as a grid, with these three concerns as one dimension. Each concern (technical, personnel, and financial) is explored along a second dimension of five foci:
- Implementation
- Integration with existing systems and interoperability
- Maintenance, application administration, and user support
- Privacy and security
- Scalability
For examples of questions you might ask to get a clear picture of a new system using this matrix, see Table 1.
| Table 1 | |||
| Matrix of Questions to Ask About New Systems | |||
| Technical | Financial | Personnel | |
| Implementation | Are there related software or hardware requirements? | How much will the hardware and software initially cost? | Who has the skills, time, and administrative rights to specify the hardware and to test and install the software? |
| How is licensing managed for the application? | Does the application require related software? | ||
| Who will use the software? Where? | Are initial training and documentation included in the implementation costs? | ||
| Integration | What data does this system need to obtain from, or send to, other systems on campus? | Are the costs of implementing links with other systems included in the implementation costs? | How will the introduction of this new system change workflow in other departments? |
| How will users of this system authenticate? | How will integration with other systems be maintained? | ||
| Maintenance, Support, and Administration | Are there effective tools to remove or archive old information; find and repair corrupted data; backup and restore some or all data? | How much does maintenance (e.g., receiving minor bug-fix releases) cost? | What roles/skills and time are needed to maintain the system? |
| How often are patches/upgrades released? | Does annual maintenance include upgrades? | Does some company provide for-fee maintenance services? | |
| How are future costs for maintenance, upgrades, services determined? | Does ongoing support require vendor training? | ||
| Privacy and Security | Does the application have a security scheme that enforces roles that permit users to do or view only what they are supposed to? | What liabilities does the system create (or mitigate), for example with respect to unauthorized access to personal data? | Who will maintain this security scheme? |
| Does the system require its own set of user names and passwords, or does it integrate with campus authentication schemes? | When personnel change or change roles, how will the security scheme be updated? | ||
| Scalability | Is there an existing system already at Simmons that might meet your needs? | How many people will use the application, and does it make a difference to the licensing costs if you negotiate for concurrent, volume, or site licensing? | If use expands, who will administer the system, if it started out being owned by one department? |
| How many people can use the system at once? | What costs would be associated with making the system available to more people? | ||
| How much data will it end up creating and how much space will it take up if you expand use? | |||
Implementation
Although implementation is often the easiest for laypeople to contemplate, working out what it takes to implement the desired functionality may include plenty of setbacks. In addition to examining software and hardware requirements, licensing (hardware or software keys; concurrent, volume, or site licenses), training, and installation, the protocol prompts consideration of whether a server is necessary (for the application or for sharing data) and whether the application is web-based. Here, the protocol refers to the related policy documents, "Web Application Assessment" and "Support and Maintenance of Departmental or Discipline-Specific Hardware and Software."
Faculty wanting to provide students with access to a desktop-based, discipline-specific application might need to consider only the implementation issues in working with Technology.
Integration with Existing Systems
This topic provides a good example of the system of questions the protocol uses to lead service owners and Technology to determine whether a given section applies. The protocol points out the importance of considering whether a proposed system will need to communicate with other campus systems. Not all applications must integrate with other systems. However, if people
- will need access to existing data (including being able to log in to an existing system),
- anticipate a need to share the data now, or in the future, or
- will duplicate data held in full or in part elsewhere,
then they should review the issues surrounding integration as they investigate the system, and they should figure the cost of integration into implementation costs. In general, implementation of a system that holds data also held elsewhere must include a mechanism for keeping consistent the data in the "parallel" systems. Typically, this means that the data can be changed in only one place and that those changes then propagate to any other places the same data are held.
Maintenance, Application Administration, and User Support
While the need for a new system and the cost of acquiring it usually dominate the proposal process, it is equally important to determine the maintenance required. Generally, think of maintenance as the effort needed just to keep the application up and running, not to actually use it. The protocol makes it explicit that Simmons service owners must consider long-term consequences of a technology decision, not just solve an immediate issue.
For users to productively employ an application, they typically need end-user support. Application administration is the collection of back-end functions required for the application to be used. It includes managing what each user is allowed to see and do with the system. All too often systems are implemented without a clear understanding of how much work will be needed by the institution for it to function effectively and keep functioning effectively.
This section of the protocol refers to the college policy on support and maintenance of departmental or discipline-specific hardware and software. It explains not only what services Technology offers but also the responsibilities of the system owner and of Technology vis-Ã -vis maintenance, administration, and support.
Privacy and Security
In general, service owners are aware of the security needs of their own data, and faculty understand rules regarding confidentiality of student records. However, it is not always easy to know or remember the nature of data owned or retrieved from elsewhere. If the system will include any sensitive information, particularly regarding students, faculty, staff, or human subjects, the protocol cautions people to review system security to ensure that their department abides by institutional standards and legal requirements. For student information, one applicable law is FERPA; for patient information, HIPAA.
In addition, Simmons is a small institution that has experienced recent growth. Faculty and staff take a small-town approach to physical security, often trusting anyone who has access to their offices when that trust is not always merited.
Even where privacy is assured through technical security measures, policies and procedures for human behavior remain critical. For example, a system might meet technical needs for security, but if people share passwords, leave printouts in the open, or download copies of data in text files, the privacy of data may be compromised. The protocol stipulates that people consider what policies they might need in connection with their system and whether it is important that anyone sign a confidentiality agreement before receiving access.
Scalability
Scalability is an important concept for both Technology and service owners to consider. When assessing a new application, there are at least two ways in which the scale of the implementation might change:
- While the first plan might have just two or three people using the system, in the future it may become convenient or necessary for more people to use it.
- Another organizational unit might already be using a system similar to the one being investigated. It may be possible to expand that system instead of purchasing an entirely new one. If expansion is not viable, it still might be possible to leverage their experience with respect to purchasing, implementation, testing, and launching the system. Or, other departments might need a similar system to the one being considered, and there is value to the institution in having unified systems for any given type of need.
Conclusion
Simmons' approach has two novel aspects. First, by placing the college's technical priorities in the hands of a representative committee, the decisions and consequences are shared. The whole decision-making process becomes transparent to the community.
Second, the Technology Systems Assessment Protocol clarifies the set of issues faced every time a new service is proposed. The protocol succeeds in making the issues of integration and total cost comprehensible to the community and a shared concern, rather than roadblocks imposed by the technorati on those just trying to get their jobs done.