Communication within ITS
Sep. 21, 2007 by ravishan
I know that this is one of those boring topics that comes up often. But this keeps coming up whenever I am in meetings with ITS staff or with faculty or other administrative staff. Rather than go into specifics, which will invariably result in miscommunication (because it may be viewed as me picking on certain groups or individuals), let us assume that there are communications issues. Of course, if you feel there are no issues, I would love to hear your comments…. (As you can tell, I am desperate for comments and I will take them whichever way they come)…
Don’t get me wrong… I don’t think anything is broken badly… We are constantly looking for opportunities to get better.
How do we communicate better within ITS? The usual process is that any major project gets vetted in the Director’s meeting and suggestions for participation by staff from various groups are made there including the project lead. Does it happen on every project? Probably not. But this has worked out reasonably well. The other way we do this is when the groups are convened to work on a project, someone there may indicate that it would be better to include other staff members in the group.
We also make it a point to discuss these projects in the Director’s meetings and Manager’s meetings and mention them in the staff meetings. In addition we send something to itstech-l periodically.
The problems arise when things get overlooked by the group at large. Everyone in the group feels that all bases are covered only to find out later that something was overlooked. And we will get to hear from other ITS staff members that this was not communicated adequately and had it been done properly, we would not have the problem we had… You get the drift.
One solution is to discuss a project in detail in a staff meeting and ask for participation. I don’t think it is productive, but may be it is… In many cases, we communicate by E-mail and obviously that is not working either because we are not doing a good job of explaining what we are trying to do or not everyone reads all these E-mails as carefully as they should.
So, what should we do? There have been talk about some technical solutions such as change management etc. Should we look at this? Will all of us participate in it to the extent required so that it is successful? These solutions don’t make the problem go away because, eventually this is not a technology problem but a human issue.
In terms of communications to the rest of the world, it is the age-old problem of striking the right balance. How much communication is the right amount? If we send too many emails, users complain and may refrain from reading them or worse, filter them out. If you send too few, they are unhappy that we are not keeping them in the loop. Our current practice is rather simple – the project team/Directors suggest that a communication should go out, then it is prepared in a way that is easy to understand and lacks the technology jazz (typically Joanne takes this responsibility), sent for proofing and then sent out.
Whereas the process takes a lot of time for each communication, it has proven valuable. Should we do this differently? For example, should we personalize this? A faculty member can choose to receive only communications relevant to certain categories, so they are not being bombarded with things that they are not interested. We already do a fair amount of targeted emails, but may be it is not enough. In the customization, by choice, an individual may choose to get mails on a lot of categories or not. She/He should be able to change it as needed.
This also means that as senders of these emails, we need to exercise a lot of care on categorizing the E-mails that are being sent.
I am therefore looking for ideas. Send them in. You can always request that a posting be anonymous if that helps…
We have some very good tools in place for communicating within ITS (itstech-l, dokuwiki, director meeting notes, and staff meetings) but consistency is a problem. The biggest mishaps seem to occur when a project is rushed or when communication is delegated to someone who already has more work than they can handle. Truthfully, we are a very busy department that handles many different projects with some very short turn around times. Everyone on staff seems to be a champion at multitasking but there is a limit to what people can handle without errors occurring. We may need to realize that for who we are and the amount of work we handle we are really doing quite well. There will always be errors and the busier we become the more errors there will be.
I would not suggest discussing all projects in detail during staff meetings. That can cause the people that are not involved in the project, even peripherally to feel that their time is being wasted.
I would like to suggest an additional step when communicating to the Wesleyan Community. When we send out the brief email, light on the technical jazz, it would be helpful to have a link that would bring the user to a page in dokuwiki containing more information including some technical jazz. This would help tech savvy users feel connected and not talked down to while parties that are not interested can avoid it entirely.
I would not suggest customizable email lists. As a user of customized email lists I can tell you with certainty that this causes great confusion for people sending messages, especially when a topic crosses multiple categories.
Hope this helps.
Jen
Jen, thank you very much for a very thoughtful response.
You are absolutely right that whereas we always shoot for error/problem-free project rollout (and we should!), it is elusive. I say to the directors and project managers that no matter how well we plan, problems are unavoidable(I tend to cite multi-billion dollar companies who have the same issue). Our strength, as you point out, has been how we respond to these errors and problems.
But, that should not mean that we should strive to minimize the problems arising from these complex rollouts.
What you suggest in terms of brief emails and links to pages with more details already exists – ITS Communication Channel Blog. Consistency is the problem!
Are we looking at the right place? Maybe what appear as communication problems are the symptoms and not the problem per se. I am wondering if where we should be looking is the process that we follow especially for major projects. Is the process well defined? Is it understood? Is it followed?
As long as we want to follow a model of “project leads” here are some suggestions to kick around:
For any major project — system or process change — you appoint a technical and a functional lead from the relevant ITS units – one of them is serving as the project lead and is given not just the responsibility but also the authority to see the project through. They have the responsibility to develop a preliminary plan that clearly identifies issues, changes etc, needed personnel, and propose time lines. The plan is considered by the directors and if approved appropriate personnel is assigned to the work team for the project. At that time through announcements in staff meetings — all ITS (not in excruciating detail), and sub-units (more detail if needed) — and the distribution list we all have a “heads-up” on what may be coming down the pike. If appropriate the project leads maintain a project wiki with relevant information that all can access — again we should not overly rely on the wiki meaning that we should think that just because we put it there everybody knows about and understands exactly what the implications are – we all know how messy wikis can get. The project leads will have the responsibility to cross all the t(s) and dot all the i(s) and when all the preparatory work is completed submit the implementation/roll out plan — which should include the necessary education and information components for users and ITS colleagues — to the directors for final approval. No change takes place unless at least two directors (of the relevant affected areas) who bear ultimate responsibility sign off on the project.
I am not suggesting that we don’t have processes like this in place — I am sure we do. It simply does not feel that we always follow them. I know that adopting and practicing change control protocols is not easy and in some cases these protocols don’t work, and/or get in the way to getting things done quickly. As much as we try there will be cases that we miss something, but I think you will agree that if we follow a process that all of us understand will minimize mishaps and at the same time reduce the friction and occasional frustration.
eik
Jenn’s first paragraph sums it up very well. the busier we become the more mishaps will occur — and no tools will prevent these kinds of issues. in the companies I’ve worked for, when this problem occurs, one of three things happens: 1) management adds another person (for the long-term; short-term people rarely do more than delay the project further), 2) management reduces the workload, or, in the case of my last project I worked on, 3) upper management ignores requests for help, subsequently the project defaults (repeatedly misses deadlines) and the company gets sued.