Collaboration
May. 5, 2009 by ravishan
I read recently President Roth’s most recent post titled “Universities in Crisis? From Compartmentalization to Collaboration“, which discusses Mark Taylor’s Op-Ed in New York Times titled “End the University as We Know It“. Both are very interesting and thought provoking.
As I was reading these, I was reminded of conversations that I have had with some of my colleagues about Technology collaborations (or the lack of it) and wanted to write about it here.
I am all for collaboration! The advantages of collaboration are obvious and I won’t go into them. It is also the case that the very nature of what we do in ITS requires that we collaborate with others in almost everything we do.
We do a great job collaborating with others on campus and I can’t think of many projects that we are engaged in that is not collaborative. However, I feel that there are many opportunities for inter or trans-institutional technology collaborations that are not being capitalized on for various reasons, primarily because institutions are unwilling to compromise. Merely having discussions on listserves does not necessarily constitute collaboration in my mind. There are so many other areas in which we can collaborate, thereby reducing duplication of efforts, and learning from each other to do things differently and better.
You will find many references on the web that tell you about the recipe for a successful collaboration. Almost all of them will specify some core ingredients (in no particular order):
- Trust and Respect – If the team members do not trust each other and respect each other, the collaboration will not be smooth sailing. Trust and Respect cannot be forced on the team members. It is a process that can some time. In several instances, the collaborators may be working together for the first time, so they need time to develop the trust. When the lack of respect comes in the way, a good project leader will detect it and resolve it in a timely manner. The success of the collaboration depends on minimizing time spent on resolving such differences.
- Strong Communication – Very clear, polite and respectful communications between the team members is absolutely essential for a collaboration to succeed. The exact amount and quality of communication depends so much on the members of the team. Disagreements are natural to collaboration, but these should be communicated in a polite and civil manner.
- Ownership and timeline – Project ownership and timelines should be clearly defined early on in the process. When it comes to IT collaborations, we typically request those who request the projects to play an important role in managing the projects because unless they “own” the project, it is unlikely to succeed. The project requestors have a deeper understanding of the project from both the functional and business process aspect as well as a much better understanding of their clientele than the technologists (there are always exceptions to these generalizations).
- Conflict Resolution – Compromise is the name of the game in Collaboration. Not everyone is going to get everything they want. However, when conflicts arise and it appears that the team is unable to resolve them, escalate it to your supervisor in a timely manner. Letting it sit for too long is a bad idea!
- Share the glory – Sharing the accomplishments of every team member when the project is complete is key to a successful collaboration. Everyone who contributed should be acknowledged so that they feel a sense of accomplishment. Of course, when the project does not go well (this does not happen around here, does it?), that responsibility also should be shared and fingerpointing will only lead to bitterness and animosity.
I can now talk a bit about how technologists tend to feel about collaborations with others. This is based on what I hear in ITS as well as many of my friends in other Higher Ed institutions and industries. The general sense is that in many cases our contributions are marginalized. Unfortunately, this tends to be more of a perception than reality. The data will show that the contribution from technologists bring tremendous value to any collaborative project. The fact that the technology is only one aspect of the collaboration does not mean that it has been marginalized. It is like making a movie – the actors and the directors tend to get way more credit than scores of others whose contributions are equally important. The same way, the functional offices may be in the front line of many projects, but the project would not have been successful without contributions from the technology staff.
Another significant factor in technology collaboration is the leveling of playing field – many of our partners are very knowledgeable about the various technologies that are available which they learn on the web. This can become a huge issue in collaborations where the non-technology partners tend to have more of a say in terms of the choice of various technologies, user interfaces and the like. This is where the trust and respect issue comes into play. As long as you, as a technologist, have trust that the recommendations are being brought to the table after careful research and thought, you should feel fine with it. As I have said before, it always helps to ask for “data” (for eg. where did one find out that technology A is better for the intended purpose than B). I have been told in some cases that these decisions cannot be data driven – well, I am yet to be convinced of any.
On to my collaborations…