7 Questions with Higher Digital's Joe Gottlieb and Joe Moreau

A second important principle of good change management is serving users as customers. Yes, students are a really important user, but if your broad team of employees at an institution is responsible for delivering value and curating the student experience, you have to make sure they're effective at using your systems as well. And so in IT, this is about delivering value as a service organization that can think about, okay, am I rolling out bite-size chunks that they're going to understand? Do I have to think about training? Do I really care about the reaction? Because if I feel like I'm done and I throw it over the transom, I'm only creating another problem. So it's taking the medicine, doing it right, serving customers, and delivering change in small chunks that are easier to digest.

And then the third principle we talk about is tracking results against objectives, and course-correcting as priorities and new information dictate. And this is where the iterations are so important. Whether you're Agile or not, it's important to give yourself the latitude to act on new information. It's okay to change priorities — it's actually super smart. There's a reflex that goes on where people say, "Oh no, no, no, we've got to stick to the plan." Well guess what? That plan was a guess at a point in time. Keep the far-reaching goal more ambiguous — like a strategic imperative, like the way you're going to measure value, like the way you're going to define success — and then iterate and adapt to what you can learn.


Moreau: The foundation of that is data about the change you're trying to make. This is one of the things that I think is really powerful about the Higher Digital methodology: We start by gathering lots of data from as many stakeholders as possible, and bringing that data and visualizing it and putting it in front of everybody to say, "We know we have this challenge. Here's what everybody thinks about it." A lot of times you find that 90% of the organization feels one way and 10% feels another way, and the people who have significant fear and anxiety about change end up saying, "Well, alright, if everybody thinks we should do it that way, then okay, I guess we need to think about it."

The other thing that I have found over many years is that people who want to be obstructionist in the change zone are eager to throw out definitive statements that are absolutely not true. I call it the mythology of IT. They say, "We can't change that because the law says this, or the regulation says that, or the policy says this, or the software doesn't do that, or students want this," and nine times out of 10, those definitive statements are simply not accurate. We have to get into a method of challenging those without being nasty: "Okay, maybe that's the case, but let's see the citation for that. And let's really make sure that it says what you thought it said or what I thought it said." First of all, it may have said that 20 or 25 or 30 years ago, but it may have changed, and we just never caught up with the change. Or it may have said that and we all thought it meant X, but we've subsequently had interpretations by counsel or the legislature, and it really doesn't mean that, it means this other thing. Or it meant that in the era of XYZ, but it doesn't mean that in the era of ABC. We have to be open to challenging our assumptions about the way we've done things, because there may, in fact, be a better way to do it.

CT: Can you share some common misconceptions about change management?

Moreau: The big one that I've seen for a long time is that institutions assume change management is a one-time thing — that we're going to do it for this project, and then once we've done it, we're done. But it really needs to become part of the fabric of the institution. It needs to be a muscle that the institution can flex regularly and consistently. The plan that we started with may not be the plan we want to keep going with, because we've learned new things through all of these discussions as we've implemented new things and we've gotten to know the product better. We thought it was going to be this way — that was a sound decision when we made it — but based upon what we know today, it's no longer sound. How do we then go back through that process to modify our plan based on new information or new assumptions about how we're going to do this?


Featured