Building IT Community on Campus

min read

© 2006 Annie Stunden

EDUCAUSE Review, vol. 41, no. 1 (January/February 2006): 72–73.

Annie Stunden is Chief Information Officer and Director of the Division of Information Technology at the University of Wisconsin. Comments on this article can be sent to the author at [email protected].

When I first put my thoughts to paper to give a brief talk about distributed-computing support providers and central IT organizations, I named the talk “Building Bridges.” But as my thoughts developed, I realized I wasn’t talking about building bridges. Bridges let people move from one side to another, which implies choosing “sides.” Rather, I was talking about building community—about developing a community that shares common spaces with common values and goals.

The term distributed support provider usually refers to those campus IT staff who are not part of a central IT organization. A distributed support provider could be an IT desktop specialist working for a specific school or college. A distributed support provider could be a UNIX system administrator managing a set of computers for a large research project. A distributed support provider could be a programmer developing reports in the registrar’s office. A distributed support provider could be a network administrator working in the computer science department. In some instances, the jobs being done by distributed support providers are very similar to those being done by IT staff in the central IT organization. In other instances, they are very different, such as the job of a scientific programmer in a research center. Distributed support providers are better connected than most central IT staff to the faculty and staff who do the core work of teaching, research, and administration. They know more than the central IT staff about how the campus schools, colleges, and departments operate.

My institution, the University of Wisconsin at Madison (UW-Madison), is huge and complex. Our central IT organization has about 500 full-time staff members and more than 200 student and part-time staff. About 350 of the full-time staff have IT job titles. In addition, more than 600 staff in the schools and departments have IT-type job titles. And we can easily identify another 250 with different job titles that support IT. Although my numbers are not exact, my sense is that there are at least twice as many IT staff outside of the UW-Madison central IT organization as there are inside it.

The IT infrastructure and most centrally provided IT services are very important to all of the IT staff on campus. The technology and services provided by the distributed support providers are often dependent on a well-functioning network and server environment, on centrally managed security services, on directory services, on help-desk services, on centrally managed administrative applications, and on network services and a myriad of other centrally provided applications and services. In the past, however, central IT support organizations have been reluctant to involve their counterparts on campus in the planning and design of these services. They sometimes accuse the distributed support providers of not understanding the complexities of keeping all services up and running regardless of virus attacks, of demanding too many unique functions and features, and of not being respectful of the many services provided by the central IT staff. On the other hand, distributed support providers have often dismissed the work of the central organization as not being good enough to keep systems up and running, as not meeting their specific needs, as not being well implemented or managed, and as not having relevance to their jobs. Yet all of us who work in IT at UW-Madison share the mission of providing technology infrastructures and services that support the university mission of teaching, learning, and research and that support our ability to administer these complex organizations. We need to work together.

Building and maintaining a community of support that spans the central IT organization and the distributed IT support providers presents real challenges. Campus IT leaders must listen to the IT staff outside of the central organization as well as to those inside the central organization and must be sure that the experience and knowledge of the entire community is used to improve the IT infrastructure and services. UW-Madison has taken at least three different but complementary approaches to building a campus-wide IT community:

  1. Encouraging more involvement by distributed support providers in setting IT policy and direction. UW-Madison has worked with existing informal organization structures and has also built a more formal governance structure that involves the leaders among distributed support providers. Together, the leaders set agendas and develop policy recommendations that are moved forward appropriately.
  2. Encouraging more involvement by distributed support providers in technical decision-making. IT architects in the central organization, as well as senior IT technical staff and project managers, invite and encourage the involvement of campus technical staff in setting requirements, selecting vendors, and designing projects. Key projects have included the development of portal, network, and e-mail architectures.
  3. Developing a three-tiered network management model. This model was developed with distributed support providers when a major investment was being made campus-wide in a new campus network, the “twenty-first century network.” This model allows colleges and departments to identify how they want to work with the central organization to implement and manage the new network. Tier 1 is central management: the central organization will manage the department/college network. Tier 2 is collaborative management: the central organization and the campus technology providers manage the network together, with each group having a specific set of responsibilities (the central organization developed a tool-set to support this model). Tier 3 is delegated management: the department/college has sole responsibility for managing the network. The cost to the departments and colleges is the same per unit regardless of which management model is chosen. Some smaller units have chosen the central management model. Most units have picked the collaborative management option. Very few units have selected the delegated management model, and some who have are now indicating they would like to work in a collaborative manner instead. There are, of course, advantages to the central or the collaborative model, primarily 24x7 network operations support.

The approaches identified, as well as the growing concerns of the entire campus IT community for more uniform IT policies and improved IT security, have served to build a large community of collaborators. But a lot of the work of community building involves putting in place opportunities that allow people to reassess old mindsets and to make new friends and allies. Central and distributed staff must give up the “us-versus-them” attitude and become welcoming of each other. Respect for the work of each and recognition of the value of the work done centrally and the work done in the distributed campus units are necessary. To gain that respect and recognition, each group needs to know what the other does. That means bringing people together in forums where people can listen to each other, in forums where recommendations are developed and decisions are made. The central IT staff must come to believe that it is their job to “do the right thing” by the distributed support providers. The distributed support providers must come to believe that the intention of the central staff is to “do the right thing” for them so that they can do their work well.

At UW-Madison, distributed support providers are invited to many meetings coordinated by the central IT staff. Distributed staff are also invited to higher education IT forums that they might not usually attend (such as the annual EDUCAUSE Midwest Regional Meeting). The central organization will occasionally cover expenses for such attendance. Distributed staff members are also invited to vendor technical presentations with central staff, both on and off campus.

We have a long history to contend with as we try to build this campus IT community. Faculty who had “not so great” help-desk experiences ten years ago can perpetuate their old horror stories. Technology staff who have been encouraged to leave the central organization and obtain positions in other units on campus sometimes leave angry at the central organization and share that anger. Finally, both the central organization and the campus departments have arrogant techies who always “know better.”

Big actions are needed to break down barriers, build community, and improve the entire campus IT environment. Governance shared among the central and distributed IT leaders, strategic and specific joint planning efforts, and productive, respectful relationships among central and distributed staff are key to building this IT community. Most important, the leaders of the central organization must be committed to building this community. The leaders must be active in developing and nurturing a cadre of IT directors campus-wide. The leaders must demonstrate their willingness to be collaborative and to talk about the benefits gained from such collaborations. They need to be “out there” attending gatherings, participating in forums, encouraging and supporting shared initiatives. And they must do so over and over again. Communities do not stay together without leaders who work to build and maintain the community. This is the job of the leaders of the central IT organization.