Lessons learned about consortial collaboration
Intercollegiate collaborations are a way of life at Swarthmore College. The Tri-college Consortium (Bryn Mawr, Haverford, and Swarthmore Colleges) shares a unified library catalog and a single Blackboard server. The three schools also allow complete cross-registration for courses. Over the past decade, I have been highly involved in three grants funded by the Andrew W. Mellon Foundation, including two with the Trico and another with the bi-coastal Web Integration and Sustainability Project. I’ve supported other consortium grants, projects, and committees in support of the Tri-college libraries.
Today I’m going to summarize my observations about long-term collaborative processes between institutions. Before I profess, let me first disclaim. What follows is based on my experiences working within the niche of information technology and library organizations at small, U.S. colleges and universities. While I strongly suspect that many of my conclusions can be extrapolated to inter-organizational collaborations in other contexts, I cannot claim to know this from first-hand experience. I also need to reinforce that my conclusions about the collaborations I've mentioned are my own, and do not necessarily reflect the conclusions of anybody else involved.
The small college context sets the stage.
Technology workers at small colleges have a long tradition of sharing tools, strategies, and information with each other in a spirit of openness. Competitiveness at the level of the technology organization would be anathema to the membership of the Consortium of Liberal Arts Colleges (CLAC), for instance. The sense of shared purpose and the investment in mutual success in this environment is a superb foundation for enabling intercollegiate collaboration.
Despite the receptiveness to collaboration, geographic dispersion and small size are ever-present obstacles in the way of successful collaborations. Unlike how such projects might be handled at larger institutions, small college collaborations rarely have participants whose sole job duties relate to the project at hand. There can be a tendency for consortium work to be seen as “extra work” beyond one’s “real job.” It’s inevitable that accountability and urgency will always be felt more directly for tasks at a worker’s home institution. Since most I.T. workers in higher education work with a degree of autonomy and self-direction, inter-institutional projects will always be a kind of optional work. Even if an individual may be recognized for exceptional contributions to an intercollegiate partnership, the consequences for failure to address local demand are more immediate and painful. There is a large “when push comes to shove” factor for partners outside a participants home institution. These challenges are greatly compounded when the colleagues competing for a worker’s time are thousands of miles away in a different time zone.
Institutional rationale matters most in the planning phase
Organizational leadership must value the participation of its employees in collaborative efforts for the levels of collaboration to be sustained. Staff will typically bias their efforts to achieve success in areas that they perceive to be valued by others. Senior managers are also vulnerable to the same “when push comes to shove” scenarios as the people who report to them. Consequently, collaboration depends on organizations willing to structure themselves for success. Senior managers need to realistically consider their ability to commit sufficient staff resources to the project. They must be sure that staff time can be freed up to enable their participation in the project; that there is appropriate accountability for the completion of project tasks; that other priorities are not likely to overwhelm the team.
The best collaborative projects are those that are difficult to accomplish but that strongly align with institutional priorities. Because of the difficulties inherent in collaborative efforts, shared projects should be scrutinized from a cost-benefit perspective. The investment of resources to get multi-institutional projects off the ground is vastly greater, and the timelines to completion are longer. Planning and consensus-building are more complex. Travel and the reliance on asynchronous modes of communication (email, discussion groups) tend to slow the pace of work. Given the overhead of coordination and administration, participant organizations should focus on collaborative efforts that meet these two criteria:
To be more succinct, collaborative projects should be terribly important, but not urgent.
Who collaborates matters most in the execution phase.
Institutions in a consortium may set the course for a planned project, but collaboration takes place between people. From this simple statement, a slew of implications follow. Here are just a few examples:
Teamwork is enhanced by social bonds, which are harder to establish between people who don't share a common coffee urn. At the outset, collaborative projects that cross organizational boundaries need to allow for the creation of interpersonal connections. A sense of commonality, or even friendship, encourages accountability and responsiveness between team members. When organizing meetings of peers from different places, coordinators should build social time into the agenda.
Turnover has a profound effect on collaborative efforts, and is even harder to overcome than its effect within the local environment alone. When an employee leaves a position, work on any project will be delayed while a new person is recruited and brought up to speed. Because of the complexities I’ve already mentioned, a new employee may take even longer to build up to full participation in a process with outside collaborators.
Personal style plays a role in whether a particular contributor is inclined to approach a task in ways that reflect and reinforce collaboration. While we can strive to expand any repertoire, a project leader must acknowledge that we often have highly effective employees in our midst whose jobs do not require frequent collaboration on large-scale projects. If advanced communication skills and an orientation toward working collaboratively are needed for important projects, those "soft" skills should be explicitly sought when contemplating assignments or hiring decisions. If an existing employee with a back-office orientation to their work needs to contribute to a collaborative process, he or she may need explicit guidance, support, or encouragement from a project manager.
The institutions invited to collaborate should be sought out for the skill compatibility of the most-likely staff contributors. These personnel factors turn out to be more important than bureaucratic similiarity between institutions. Five schools of similar size and selectivity with very different technical environments will not get as far on a programming project as would five schools with different College guide profiles who had all made strategic commitments to PHP/MySQL and XML development.
Process lessons learned
Make somebody responsible for nurturing the collaboration. Projects inevitably reach roadblocks or stalling points. At these times, it’s important to have people whose built-in role is to reinvigorate the process. Although there are certain things we might do differently, I think one of the most successful strategies of the WISP project was the naming of a so-called “Ops-manager” at each institution. These people were charged with checking on the progress of various working groups and encouraging contributions to group activities.
There is no substitute for being in the same place at the same time. Forget videoconferencing. It’s a technology that has its place, but for the kind of long-term work discussed here, it’s a terribly stale mode of communication. The WISP group settled on a three-tiered approach that seemed to work as well as we could make it. We used a Blackboard site to manage day-to-day questions and document sharing, and to coordinate simple administrative tasks. Regular telephone conference calls helped to keep momentum going in small stages. Most importantly, two to three times a year, we punctuated our efforts with meetings or workshops. The greatest leaps forward always surrounded our gatherings, which reinforces the importance of both building community and creating time to focus on the project.
Design the process to account for unequal participation. The WISP project spent a lot of time struggling to agree on the selection of tools and priorities. This difficulty was exacerbated by our early reliance on task forces that had representation of all four schools. Since flexibility and speed are already at a premium in a group process, it would have been more productive to envision our collaboration as a series of smaller projects, some of which might have formed organically where any two or more participants shared a common interest that they wished to pursue. For a long-standing collaboration, I strongly encourage a more dynamic, modular structure over a more lumbering, bureaucratic one. The Tri-college was faced with an interesting situation recently, which demonstrates how success does not require everybody to be on the same wagon. All three schools share a common Blackboard server hosted at Swarthmore College. Two of the schools wanted to also license the Blackboard Portal. Rather than exert effort trying to persuade the participation of the third school, the first two went about licensing Portal on their own. The third school is welcome to join the party at any time, but in the meantime, the schools that were ready to move forward have not been slowed down by a need for absolute consensus.
Here concludes the brain dump on issues of intercollegiate collaboration. Please add your own ideas in the comments section for this post.
Today I’m going to summarize my observations about long-term collaborative processes between institutions. Before I profess, let me first disclaim. What follows is based on my experiences working within the niche of information technology and library organizations at small, U.S. colleges and universities. While I strongly suspect that many of my conclusions can be extrapolated to inter-organizational collaborations in other contexts, I cannot claim to know this from first-hand experience. I also need to reinforce that my conclusions about the collaborations I've mentioned are my own, and do not necessarily reflect the conclusions of anybody else involved.
The small college context sets the stage.
Technology workers at small colleges have a long tradition of sharing tools, strategies, and information with each other in a spirit of openness. Competitiveness at the level of the technology organization would be anathema to the membership of the Consortium of Liberal Arts Colleges (CLAC), for instance. The sense of shared purpose and the investment in mutual success in this environment is a superb foundation for enabling intercollegiate collaboration.
Despite the receptiveness to collaboration, geographic dispersion and small size are ever-present obstacles in the way of successful collaborations. Unlike how such projects might be handled at larger institutions, small college collaborations rarely have participants whose sole job duties relate to the project at hand. There can be a tendency for consortium work to be seen as “extra work” beyond one’s “real job.” It’s inevitable that accountability and urgency will always be felt more directly for tasks at a worker’s home institution. Since most I.T. workers in higher education work with a degree of autonomy and self-direction, inter-institutional projects will always be a kind of optional work. Even if an individual may be recognized for exceptional contributions to an intercollegiate partnership, the consequences for failure to address local demand are more immediate and painful. There is a large “when push comes to shove” factor for partners outside a participants home institution. These challenges are greatly compounded when the colleagues competing for a worker’s time are thousands of miles away in a different time zone.
Institutional rationale matters most in the planning phase
Organizational leadership must value the participation of its employees in collaborative efforts for the levels of collaboration to be sustained. Staff will typically bias their efforts to achieve success in areas that they perceive to be valued by others. Senior managers are also vulnerable to the same “when push comes to shove” scenarios as the people who report to them. Consequently, collaboration depends on organizations willing to structure themselves for success. Senior managers need to realistically consider their ability to commit sufficient staff resources to the project. They must be sure that staff time can be freed up to enable their participation in the project; that there is appropriate accountability for the completion of project tasks; that other priorities are not likely to overwhelm the team.
The best collaborative projects are those that are difficult to accomplish but that strongly align with institutional priorities. Because of the difficulties inherent in collaborative efforts, shared projects should be scrutinized from a cost-benefit perspective. The investment of resources to get multi-institutional projects off the ground is vastly greater, and the timelines to completion are longer. Planning and consensus-building are more complex. Travel and the reliance on asynchronous modes of communication (email, discussion groups) tend to slow the pace of work. Given the overhead of coordination and administration, participant organizations should focus on collaborative efforts that meet these two criteria:
- The outcome of the project should be of vital strategic importance to the institution;
- The need for project deliverables is sufficiently far into the future that the project can be completed by realistic deadlines.
To be more succinct, collaborative projects should be terribly important, but not urgent.
Who collaborates matters most in the execution phase.
Institutions in a consortium may set the course for a planned project, but collaboration takes place between people. From this simple statement, a slew of implications follow. Here are just a few examples:
Teamwork is enhanced by social bonds, which are harder to establish between people who don't share a common coffee urn. At the outset, collaborative projects that cross organizational boundaries need to allow for the creation of interpersonal connections. A sense of commonality, or even friendship, encourages accountability and responsiveness between team members. When organizing meetings of peers from different places, coordinators should build social time into the agenda.
Turnover has a profound effect on collaborative efforts, and is even harder to overcome than its effect within the local environment alone. When an employee leaves a position, work on any project will be delayed while a new person is recruited and brought up to speed. Because of the complexities I’ve already mentioned, a new employee may take even longer to build up to full participation in a process with outside collaborators.
Personal style plays a role in whether a particular contributor is inclined to approach a task in ways that reflect and reinforce collaboration. While we can strive to expand any repertoire, a project leader must acknowledge that we often have highly effective employees in our midst whose jobs do not require frequent collaboration on large-scale projects. If advanced communication skills and an orientation toward working collaboratively are needed for important projects, those "soft" skills should be explicitly sought when contemplating assignments or hiring decisions. If an existing employee with a back-office orientation to their work needs to contribute to a collaborative process, he or she may need explicit guidance, support, or encouragement from a project manager.
The institutions invited to collaborate should be sought out for the skill compatibility of the most-likely staff contributors. These personnel factors turn out to be more important than bureaucratic similiarity between institutions. Five schools of similar size and selectivity with very different technical environments will not get as far on a programming project as would five schools with different College guide profiles who had all made strategic commitments to PHP/MySQL and XML development.
Process lessons learned
Make somebody responsible for nurturing the collaboration. Projects inevitably reach roadblocks or stalling points. At these times, it’s important to have people whose built-in role is to reinvigorate the process. Although there are certain things we might do differently, I think one of the most successful strategies of the WISP project was the naming of a so-called “Ops-manager” at each institution. These people were charged with checking on the progress of various working groups and encouraging contributions to group activities.
There is no substitute for being in the same place at the same time. Forget videoconferencing. It’s a technology that has its place, but for the kind of long-term work discussed here, it’s a terribly stale mode of communication. The WISP group settled on a three-tiered approach that seemed to work as well as we could make it. We used a Blackboard site to manage day-to-day questions and document sharing, and to coordinate simple administrative tasks. Regular telephone conference calls helped to keep momentum going in small stages. Most importantly, two to three times a year, we punctuated our efforts with meetings or workshops. The greatest leaps forward always surrounded our gatherings, which reinforces the importance of both building community and creating time to focus on the project.
Design the process to account for unequal participation. The WISP project spent a lot of time struggling to agree on the selection of tools and priorities. This difficulty was exacerbated by our early reliance on task forces that had representation of all four schools. Since flexibility and speed are already at a premium in a group process, it would have been more productive to envision our collaboration as a series of smaller projects, some of which might have formed organically where any two or more participants shared a common interest that they wished to pursue. For a long-standing collaboration, I strongly encourage a more dynamic, modular structure over a more lumbering, bureaucratic one. The Tri-college was faced with an interesting situation recently, which demonstrates how success does not require everybody to be on the same wagon. All three schools share a common Blackboard server hosted at Swarthmore College. Two of the schools wanted to also license the Blackboard Portal. Rather than exert effort trying to persuade the participation of the third school, the first two went about licensing Portal on their own. The third school is welcome to join the party at any time, but in the meantime, the schools that were ready to move forward have not been slowed down by a need for absolute consensus.
Here concludes the brain dump on issues of intercollegiate collaboration. Please add your own ideas in the comments section for this post.
posted by EB at 6:00 PM
Site Feed
0 Comments:
Post a Comment
<< Home