Many of us will by now be aware of a change at the start of this month to the name of the College of Humanities & Social Science (CHSS), which was renamed to the College of Arts, Humanities & Social Sciences (CAHSS).

Small name changes in the University’s organisational structure are pretty common, but it’s unusual to see one at such a high level – in fact the this is the first time the College has made a change to its name since it was founded in 2002. And while that date might seem relatively recent on the scale of a venerable institution like the University of Edinburgh, it’s positively generational in terms of our computer systems.

We thought we’d take a quick look at what these changes mean for just one of our services – in this case UniDesk, which is our service management and support tool.

As the Service Manager for UniDesk, I have a keen interest in making sure that we avoid disruptions in the service. I manage changes within the service as effectively as possible, but sometimes changes which will affect the service – like this one – are external to it. Where changes are coming in from the outside, I’m concerned with making sure that we understand their implications, and making the right decisions as to how to deal with them.

So the first step we took was to ask ourselves – what could this change mean for us?

When you’re thinking about how a service will be affected by a change, your mind tends to go to the worst outcomes – an outage or some kind of major disruption. In that sense, this kind of a change is very low risk. Data changes in UniDesk all the time.

But that doesn’t necessarily mean that we’re in the clear; we also have to consider how the core values of the service might be affected.

Such as reporting.

Reporting is one of the keystones of UniDesk. It’s what makes it worth filling in all the fields and gathering all the data in the first place. You spend the extra time categorising a call, because it gives back a lot of value in management data. It can help us make better decisions based on all sorts of things, such as the time of year we have peak demands, the services which get the most requests, or maybe… the College our users are associated with.

So a name change shouldn’t be any real problem, of course. But would UniDesk treat this upstream change as a simple name change? Our early investigation suggested that it wouldn’t – in fact, it would treat the name change in the organisational structure as if it were a whole new College. And then it would move more than a hundred and fifty thousand applicants, staff, students and alumni from the old College to the new one. Overnight.

Now, it sounds like moving all of those users to a ‘new’ College would be a big change, but it isn’t necessarily a bad one. Actually the answer depends on the circumstances rather a lot. As I say, we see this kind of change a lot, albeit on a much smaller scale, when teams working in UniDesk change names, merge with other teams, change roles, etc.

The impact of moving our user base (in UniDesk) to a new College, would be that there will be a break in the reporting data. Up to a certain date, callers will have been in one college. And after that date, they would have been in another.

Generally speaking, if the role or function of the organisational unit is changing, it makes sense to reflect that in the data. Otherwise, you can see some uncomfortable changes in the metrics you’re capturing, that you then need to be very careful to explain. The advantage of a hard break in data is that it helps you to explain the data more easily, and is more reflective of what actually happened in the real world – there was a time before, and a time after, and if the service wasn’t really consistent between the two, then it isn’t always helpful to see the data as consistent, either.

On the other hand, the change of name to the College wasn’t associated with any significant changes in function, so in a case like that it makes more sense to keep the data consistent, to make reporting simpler. While technically there was still a time before the change and a time after the change, the essential administration of the College did not change, and so being able to look at the data consistently across that whole timeframe does make sense.

With that in mind, we consulted with the major business stakeholders to make sure we were all on the same page, and then we went ahead with a planned change of name in UniDesk, in order keep the data consistent.

This was a change that had to be right first time, and it was coming at a certain date and time, so we needed to be prepared to take action in a timely way. Fortunately we’re blessed with a rather complete testing environment, so we were able to get a lot of confidence about the outcome in advance.

We actually put the main import on hold, in order to give ourselves time to work through the situation, and then managed the subsequent imports carefully to make sure that the name change took as expected. Within just a few days we were back up and running the regular data imports, and could see that our changes had taken well. To round off the whole process, we let the stakeholders know that the work was complete, and had been successful.

From my perspective, this is a great example of how sometimes managing services, even at a very operational level, can be about considering not just whether the service is working, but also whether it’s delivering the value it should deliver in the most effective way.

It’s also an example of not just of how a technical change can have a business impact, but also how a good sense of awareness of the business can help to determine which technical steps should be taken. In other words, the right answers depended on what the business was looking for, not on where the technology was taking us – and that, of course, is how it should be.

What’s in a name? / Information Services Applications Directorate Blog by is licensed under a