Departmental Support Plan, 19 January 1999 Draft, p. 1
Comprehensive Strategic Plan for Information Technology at the University of Virginia Departmental Support
Draft 2—19 January 1999 UCIT, Departmental Support Work Group Brian Davis, Charles Grisham, Teresa Lockard, Randy Smith
Introduction
We do not know what information technology will look like in five years, much less ten. However, the rapidity and unpredictability of change in IT means that the University must have in place a continually improving departmental computing support infrastructure if its institutional IT excellence is to survive that inevitable change while simultaneously providing for the increased use of technology by both leading-edge and non-leading-edge faculty and staff. Just as the Desktop Computing Initiative (DCI) seeks to make technology purchases a regular, continuing part of the budget process for schools and departments, the technology support infrastructure must be an integral, appropriately funded part of the decentralized University structure. The health of the support infrastructure depends on improvements in organization, compensation and training.
Creative financial resource development
We recognize that additional resources will be needed to fund the goals outlined below; however, the coordination efforts planned should reduce the amount of money it would otherwise be necessary to spend to accomplish the same ends. As with the DCI, the ultimate goal is not to reduce absolutely the cost of support but rather to decrease the staggering rate of growth in such costs. Resources obtained through a “Campaign for Technology” could be used to obtain up-to-date equipment, hire new support staff, raise support staff compensation to industry norms, and provide training opportunities to maintain the currency of support staff skills, all of which would significantly improve departmental support.
Greater systematic attention to instructional and/or academic computing environments
A previous UCIT work group identified the following broad objectives for departmental computing support:
Departmental Support Plan, 19 January 1999 Draft, p. 2
Wide discussion and discovery of the appropriate use of information technology Information technology transfer to “non-leading-edge” faculty and scholars Continued and increased focus on “leading-edge” innovations and exploration
Each of these objectives assumes that computing support structures will not simply provide the traditional skills of basic equipment installation, preventative maintenance, reactive troubleshooting and rapid repair for office computers. Instead, each envisions a support structure that supplies systems analysis, extensive training, intensive mentoring and collegial knowledge exchange for the generalized use of technology in administrative, research and instructional settings. In order to corral the human resources necessary to support these goals, an organized effort is required to hire, train, retain and manage a highly-skilled professional support staff. This effort requires institutional changes in organization, compensation and training. Organization Within the University each school and the College must take ultimate responsibility for technology support within its jurisdiction. Given the importance of this support for the overall mission of the University, this responsibility should be formally recognized within the organizational structure of each school and college, and in some of the larger business units as well. Chief Technology Officers We recommend the establishment of a Chief Technology Officer (CTO) in each school, college and business unit at the University. The CTOs would combine managerial and communications skills with intimate knowledge of the technology tools used and/or needed by their unit. The CTO should be at the Associate Dean (or equivalent) level, with concomitant authority in budgetary, supervisory and planning areas, including charges to: develop a technology plan (including participation in the DCI as appropriate) develop a staged strategy and budget for implementing the plan hire and supervise Local Support Partners (LSPs), Classroom Support Partners (CSPs) and Research Support Partners (RSPs), which could be organized by building and across departments serve as the leader of the unit’s technology effort and as the interface between the unit and ITC; a council composed of all the University’s CTOs would facilitate communication and coordination across units, as well as between the units and the University’s Chief Information Officer (CIO)
Departmental Support Plan, 19 January 1999 Draft, p. 3 A similar model is currently working successfully in some of the University’s professional schools. However, this is not an effort to impose a particular management style or rigid organizational schema onto the individual units; it is an effort to establish both accountability and responsibility. The single most important task of CTOs would be to develop an appropriate relationship with the departments and faculty of their unit, creating mechanisms within the unit’s culture to facilitate technology use fitting the unit’s specific needs. Just as every unit has a financial officer but each has a different internal budgeting process, every unit should have a technology officer but each will be free to establish its own priorities, goals and procedures. For example, in one of the professional schools the CTO may choose to establish a single set of policies for all departments, while in the College of Arts and Sciences the CTO may choose to have differing plans for departments with disparate needs. Support Partners All faculty and staff members at the University should have access to technology support from within their unit from a Local Support Partner (LSP). Some departments may have several LSPs, while others share a single LSP across three departments, but the CTO should ensure that everyone has access to a support professional, eliminating the gaps in coverage that currently exist. LSPs should be full-time salaried positions, and LSPs should be paid by and be directly responsible to the CTOs. LSPs would work locally for a specific department or building, serving as an advocate for their clientele, analyzing their needs and communicating them to the CTOs. The present situation, with many LSPs essentially operating in unfunded or part-time positions or answering to supervisors who may not understand either the details or the implications of what LSPs do, is unworkable. Technology cannot be implemented and managed by people working for supervisors who do not understand their problems and goals. In many situations (to be determined by the CTOs), additional support staff (to be supervised by LSPs) may be necessary. CSPs should be hired by building and across departments to support instructional needs in specific classrooms. As explained in the Specialized Facilities and Research portions of this plan, RSPs are needed to assist faculty with leading-edge technology appropriate to their field of research. The existence of cross-departmental technology-enabled classrooms and research computing facilities will expand access to leading-edge faculty in smaller departments that may not have enough of a demand to provide facilities of its own. As appropriate, LSPs, CSPs and RSPs could serve as back up for one another. Finally, in a less formal way, Local Support Associates (LSAs)—non-technical, usually clerical, staff who by experience and modest training have obtained the skills to provide rudimentary front-line support for common software and network questions, can continue to provide basic assistance to their office neighbors. Compensation and Training
Departmental Support Plan, 19 January 1999 Draft, p. 4 The LSP program, while making the most of the limited resources available to it, cannot hope to improve and mature unless LSPs earn salaries that are competitive and unless LSPs receive adequate, ongoing training. At present, LSPs perform a broad variety of often ill-defined duties, from crawling around under desks plugging, unplugging and debugging, to much higher level activities in the long-range planning of technology implementation. Moreover, most LSPs lack a career development path. With better salaries, appropriate job descriptions, ongoing training and prospects for advancement, we could attract and retain more competent people in these positions. For example, on the training side, a fund could be developed to provide a fixed amount of training funds to be used annually by each LSP as appropriate for his or her current job requirements and/or career development. Similar problems and solutions apply to CSPs and RSPs, as well. Part of the problem is that current job descriptions for technology-related jobs are hopelessly out-of-date, reflecting a time when “computing” denoted only mainframes and coding. In the short term, we should do a better job of classifying and assigning LSPs and related personnel. Using the CTOs to assess and assign these positions would be an improvement over the current inconsistent classification of staff across departments, with similar tasks being performed by people at greatly varying grade level. [The previous draft said it would “be very difficult” to rewrite the job descriptions and offered up the short term solution above. I’ve decided to argue boldly for taking this “very difficult” step. Let me know what you think.—BD] In the long term, however, if the University wishes to be competitive, it must undertake the comprehensive rewriting of computing job descriptions both to reflect contemporary skillsets and duties and to grade more accurately positions that fall under the computing rubric even though they involve dramatically different tasks. The University of California, Berkeley, our archetypal peerinstitution, has gone through this same process over the past year, thinking it an important enough task that they have not waited for the other UC campuses join the process before proceeding. In addition to the systematic reclassification of positions, new, higher, paylevels were established (see attachments). The University should begin a similar process within our own office of Human Resources, taking the issue to the Commonweath if necessary. [I will have the attachments in hard copy tomorrow; here are the URLs so that you can read them now: short introduction programmer/analyst matrix computer resource manager matrix reclassification questionaire] If you think more detail on this is needed, I’ll be happy to research this more with my old boss, the Director of the Chancellor’s Office Information Systems at Berkeley; the descriptions are much clearer (and more cognizant of the extent of people’s duties) and the pay much higher than when I worked there three years ago.]
Conclusion
Departmental Support Plan, 19 January 1999 Draft, p. 5 The University and ITC are clearly moving toward a decentralized, distributed model of service and support. However, implementation of that model is being compromised by the present state of affairs. The establishment of CTO positions, the reorganization of LSPs under the CTOs, and the establishment of staff working under LSPs to do low-level maintenance and support, would provide a more stable environment for control in the decentralized, distributed model. Better compensation and training would further stabilize support by reducing turnover and job dissatisfaction. This improved environment would be much better suited to provide the increasing level and sophistication of technology support required by faculty and staff in instruction, research and administration.