I’ve blogged in the past about communication (importance of first contact, and how communication should help you deal with service outages) and during my first year a year at the Clinical School Computing Service (CSCS) I’ve developed a plan for communication, and started making contact.
This might sound trivial, but with over 2,500 customers spread across 5 sites, and consisting of University Academic, Research and Administrative staff, making contact isn’t as simple as it seems.
The aim is to better understand our customers needs, so we can make sure our services fit.
As I’ve said before I don’t think user groups and committees are an effective method of gathering requirements, I need a more comprehensive view, gathered in the most efficient way possible. It’s not possible to get everything I needed from just one person in each organisation, I need an approach which covers all levels.
One to one
I need to speak to people who understand what their department does at a high level and in some detail, and preferably have the authority to speak on their department’s behalf. Speaking to the Head of Department or Principle Investigators (PI’s) is very difficult because they have very full calendars. Speaking to specific researchers or academics runs the risk of gathering a limited set of requirements. The perfect combination of operational involvement and authority I’m looking can be found in the Departmental Administrators and Business and Operations Managers. I’m setting up meetings with these managers, both to talk about our service now (good and bad) and how our service could develop to better fit their needs. Having opened this dialogue the intention is for it continue, to give both parties an informed and authoritative contact to help maintain and develop the relationship between CSCS and our users.
One to many
With the common requirements dealt with through discussion with Departmental Administrators and Business Managers, I still need to dig into the detailed technical requirements of teaching and research staff. This is not a group where I can pick out one or two individuals, there will be dozens in each department and all are important. The approach I’m taking here is to use surveys to make initial contact and build a basic knowledge of user requirements, and (as above) use that survey as the beginning of a dialogue to maintain and develop that understanding. Not everyone will want to be part of any subsequent discussions, but at least I should have a representative group of users who understand both their work, and possibly their colleagues’ work.
Build and maintain momentum
Once I’ve made initial contact with all the department via meetings and surveys the most important thing is to build on that initial contact, and maintain the momentum. Personally I find this bit fun, it’s about relationships, communication, sometimes debate, and it always presents interesting challenges. It also makes a lot of my job easier, as suddenly we have a strong flow of information into each department, and our users become more informed about what we’re doing, how our systems work, and how to make best use of the services we offer.
How I maintain that moment I’m not yet sure, I need to strike the right balance between timely and useful communication, and information overload. Social media will probably be a part of this, our new website certainly will, and those are the developments I’ll be working on this summer.