Tech vendors need to understand a few things if they want to deploy their products (and keep them updated) in Higher Education. Deploying products to faculty, staff, students, alumni and everyone in between, means that administrators have to support those diverse populations. Depending on the purpose or kind of software, some of those users may need a lot of help, or none at all.

In no particular order, here’s some areas to consider.

1. Consumer vs Enterprise Grade

If there’s one thing that you’ll hear Higher Ed IT people gripe about, it’s that more software needs to be “enterprise ready.” Loosely translated, this means that there should be additional things available; not for end users, but for the administrators and support staff. This is balance of course, as users (especially students) have come to expect consumer-grade services, and will just go (or try to go) around IT if they can’t get access to the tools they need or want.

Administrators cannot rely on end-users to enforce their own settings for best-practice or compliance….those things must be handled centrally. End-users can be allowed to change certain things of course, but IT staff must set defaults (and non-changeable settings) that align with the institution’s policies/procedures for things like security and acceptable use.

There should be parity of configuration options between the UI and API. But that’s for a future article.

2. Test vs Production Environments

Traditionally, IT systems and services would have multiple tiers of the same service, such as Sandbox, Development, Validation, Production.

IT needs to be able to verify features, configurations, behaviors, security risks and all potential impacts BEFORE deployment to end-users.

That does not mean every single service needs 3 tier environments. But, it does mean that IT staff need the ability to test things on a certain group of users, without affecting the rest of the population. Maybe this is handled by providing a “development” instance of the service. Maybe this is handled within the same environment using another kind of separation, like membership in an “early adopters” group.

3. Opt-out or Opt-in?

One of the main benefits of implementing modern cloud-based software services, is that IT staff don’t need to develop their own upgrades or patches or features; that’s handled by the vendor.

When Google rolls out a new widget for Gmail, it’s not the school IT administrator who is developing the widget BUT it is that admin who gets called if the widget causes problems/questions for users.

It’s important that there’s an ability to choose whether the new widget is opt-in, or opt-out. These abilities should be granted to both end-users and to IT administrators.

Here’s a potential timeline/approach for rolling out a new feature…with sufficient time in between each stage:

1. Allow IT admins to opt their school in or out to begin with
2. Allow IT admins to selectively opt-in certain users or groups of users
3. Allow end-users to optionally opt-in
4. Enforce the feature, but allow end-users to opt-out
5. Enforce the feature and don’t allow opt-outs.

This type of phased timeline allows the vendor to move their product/service forward and not have to support old features forever…while balancing the need for IT staff to control the specific rollout based on their campus’ culture/needs/risk posture etc.

4. What we have here, is a failure to communicate

Don’t email end users directly without telling IT first.

Ever.

Period.

Seriously. Don’t.

Even if a vendor thinks it’s a pretty innocuous email or in-app prompt kind of notification or communication that doesn’t change anything, or isn’t a big change…don’t do it without informing IT first.

IT staff are front-line support. It’s who the users go to for questions. If they get a prompt inside an app that’s confusing, or if a widget changes position, or if users get an email telling them something “important” from a vendor directly…..they’re going to ask IT about it. Some of the good users may report it as phishing, because it looks kind of legitimate, but unexpected. Still, if IT hasn’t seen the email first, or hasn’t researched its impact to their campus, the vendor is just causing more stress and scrambling, and problems unnecessarily. Early release notes delivered via standard blog/email/rss/twitter/anything is the LEAST thing a vendor should do.

It’s not unusual for a faculty member to get a vendor email and have questions, but they’ll ask their department head, who asks their Dean, who then asks the Provost, who then asks the CIO, who then asks an IT Director, who then asks the IT admin, who doesn’t have any clue what they’re talking about because they haven’t seen the email yet either….you see where this leads right? It’s bad for the IT group to have no idea what this email is, or who it went to, or what the impact is before its sent.

So vendors, give the admins a heads-up WELL IN ADVANCE of any direct emailing you might be thinking about.

4a. Who is affected anyway?

If a feature is going to roll out, who will it affect? All users regardless of any other attribute? Maybe it’s only users who use a certain feature within the software. Maybe it’s only users who created some content in a certain way, and so only those users are affected.

Communications (from the vendor or the school) need to be targeted appropriately. Emailing ALL users when only a small percentage of them are actually affected by the change will cause unnecessary confusion and support calls.

Hey vendors…tell us who is affected…like…seriously….just give us the actual usernames, and we can help with communication, or handle it ourselves. That way we know EXACTLY who, and not be left guessing what % of our campus might be affected.

5. Check the calendars

In the USA at least, most schools have 3 main schedules that vendors should be aware of:

1. Fiscal Year: Usually June/July through to next June/July
2. Academic Year: Term-based for Fall, Spring, Summer terms
3. Calendar Year: January through December

Vendors should be aware of these general schedules, and how they relate to their own products & services. It should go without saying, but some vendors don’t really understand that they should not make massive changes to their software that take effect in the middle of August.

August/September is typically the start of the Fall term, which usually sees the largest influx of new students (bigger than the Spring term). It’s the time of year that is usually the most critical for higher-education institutions. Making big changes at the start of Fall for a Learning Management System (LMS) would be tremendously risky.

Making unannounced changes (or changes without sufficient testing/ planning/ user-acceptance) to finance-related software during April through June might also not be a good idea, considering the impact on tax season, or the end of the typical fiscal year.

The calendar year can also relate to certain operations or processes, especially those interacting with external entities that may be based on January through December. Healthcare and benefits schedules seem typically linked to calendar years, and there will be IT services that interact with those of course.

Talking to institutions, understanding the critical times of the year, impact (perceived or real), and providing controls about how the changes are rolled out to the campus, can help mitigate the risks.

6. Analysis, Reporting & Documentation

IT staff will need access, reporting & troubleshooting capabilities. They need to be able to efficiently analyze and report on user-behavior or configuration options at scale because no one wants to manually click through thousands of screens or attributes by hand for thousands of users.

Vendors need to provide accurate and updated documentation ahead of the deployment of new features. This will help IT staff prepare and measure potential impact, but also update their own documentation in an internal knowledge-base or intranet.

Institutions usually try to point to vendor documentation wherever possible, because the rate of change is too rapid to keep up with…BUT…there will always be some kind of custom documentation handled by the IT staff to meet the specific needs of their school. Usually it’s to link vendor features to the school’s business processes, standards and policies, or just to explain campus customizations or best-practices.

7. Purchasing, Legal, Governance and all the other things

This one is pretty simple. Higher Education purchasing processes are not built for speed. They are built for standards and compliance. Vendors who update their terms of service, acceptable use policies, or contract terms during renewals need to think about how long it “should” take, and then double the estimate. IT staff will need to get the institution’s purchasing office, or lawyers, or security office, or numerous others involved, depending on the scale of the change.

It’s never just a case of putting a software purchase on the credit card, and clicking “I Agree” and “Download Now.” Just figuring out who has the authority to click “I Agree” can be an arduous process. Should it be difficult…no, of course not. But is it difficult and different at every school….yes….yes it might be.

Closing thoughts…

There are likely many other considerations to successfully deploying and updating software/services in Higher Education. In the interest of time and length, just know that there are other areas too.

Vendors need to spend time trying to understand the technical constraints, such as availability of a test/dev environment, or the impact of the calendar on when an update could be possibly deployed.

Engaging and talking to their higher-education customers to understand the situation on each campus, will go a long way to making their particular software/service successful.