I began writing a draft of this after the place I worked at as we were decommissioning one of our institution-wide systems and thought about the other side of the process, onboarding systems. Of course, the end of the line is a natural place to do some reflection. I won’t dig too deep into the specifics of each (that would require a beer or two to lubricate the wheels) – but I’ve been parts of teams that introduced (cumulatively) 10 new organization-wide systems over the last two decades, across three education institutions. I’ve also been part of decommissioning upwards of 15 or 16 different organization-wide systems. It’s a skill I’ve developed.
So where to start with tips? Use the vendor. They are still looking to impress you, so make sure you use their implementation process. Make sure you take advantage of every single opportunity to get to know them, how they think. As an administrator on a system, it really helps to understand the assumptions they’ve made to get to the decisions they made about designing the system. Attend their promo webinars, read almost anything you can about the system.
Talk to others who use the system. The vendor will likely give you someone who loves the system and they’re useful, but look at the list on their website of institutions and cold-call. Work your network. Search Twitter. Look for who replies to their tweets/social media and see if they are actually using the system. Yes, it’s detective work, but it’ll likely show you what you’re in for when you actually get the system stood up. This forms an informal community of people you can reach out to when the vendor doesn’t understand your questions, or when you don’t want to ask the vendor.
Get stakeholders involved early. Get Equity and Inclusion involved before you sign anything. Get accessibility and privacy involved before you sign anything. Don’t be a bungler who buys a thing, and then talks to the Privacy Office and Equity. Make it part of your purchasing process (even if it’s not required). Equity and Inclusion has an opinion about tech, especially in light of the millions of whitewashed claims out there about AI and all sorts of stuff. Even more innocuous stuff about language choices – where we can help make things more equitable easily. Having those voices at the table are, in my opinion, crucial.
Plan out you transition and add time to that plan. My rule of thumb is times everything by 1.5. If you can afford to, triple the time. You know it’s not going to go smooth. For a transition – remember you’re doing double work – decommissioning one system while onboarding another – that requires people to do work while you’re occupied.
STORY TIME!
When we did a system switch, the vendor was in the middle of a major overhaul of the system and we had a month to onboard and get people going. The onboarding and late adoption cost 40 hours overtime (including working on a holiday at 2.5 times pay) and something like 100 lieu hours. It would have been helpful to draw out the five-year plan (even if the contract was three years) and identify over the next five years, who’s doing what. Who’s job is it to be promoting this tool? What’s the communication plan for expressing the value of the tool? Who does that? You don’t have to set metrics to achieve – but you should expect early growth and adoption, then settling. What does that look like? Say you start with 15 courses using a tool, who supports that tool? What happens if they get sick? Leave the institution? Lay all that stuff out in writing. The person that gets sick or leaves might be you. Ambiguity at this point is a death screetch heard across the heavens. It kills buy-in and confidence in the long-term support of the thing. If it’s only a short-term solution, that’s fine, make sure folks know so that they aren’t envisioning a long-term solution on something that is going away next week.
The next time the team negotiating the contract (this time for web conferencing) took all the time and left us a month to implement and switch. We did it, but the money saved was eaten up by overtime and lieu time. I swore I would never do that again. The very next time they gave us less…. and it ended up costing more. So now, I know when contracts are up and I’m asking a year (or more) in advance things like “are we renewing?” Of course, I have bosses that ask me about this sort of stuff now, and I have some influence… but not everyone is so lucky. To that end, sometimes there are things you cannot control. Be honest with your users about where the issue is – even if it’s with you. If you’re within six months of the end of the contract and folks are talking about pulling the plug, make sure you’re getting extra people to manage the transition. I work with bona fide rockstars. As a group we can do pretty much everything in whatever ridiculous timeframe you can do. However, there’s a functional limit. As a lead, I know what our functional limit is, and it’s my job to make sure my bosses are aware of how close we are to functional limits.
Lastly, make sure your ebullient supporters are tamped down a bit. Let them know, you love their enthusiasm, but not everyone is on the same page. It can be offputting to have ardent followers of a tech solution be cheerleading in the face of skeptics. All that does is create a divisive atmosphere that doesn’t end up helping anyone.