I'm Just a Feature: How Tool Changes Make Their Way Into Boise State Tools

I'm Just a Feature: How Tool Changes Make Their Way Into Boise State Tools

A nod to Schoolhouse Rock!, this article explains the real steps that go into tool features and functionalities being turned on, left off, edited, or continued testing.

For all of the supported Boise State tools, a handful of OIT staff and teams administer and stay up-to-date on tool companies' news, upcoming features, outages, and so on. Some features or functionalities have “pushed updates,” which make changes to our tools without LTS intervention. Most features and functionality changes are opt-in and communicated ahead of time.

Feature Testing and Selection Process

Each member of the LTS staff specializes in a few tools they administer for Boise State. Once we have received information from the company that there is a planned feature/tool deprecation or upcoming addition, LTS staff:

  1. Connect with our vendor contact to gather more information, ask questions, and find out any additional information needed for testing the new features or functionality.

  2. Test all features and functionality in test spaces first, then in the live tool production space. While testing, we take notes about which features are ready (not buggy, clear user benefit or tool improvement) or not ready (buggy, causes downstream issues, is missing core functionality).

  3. Make note of viable features and functionality, and bring a suggestion to LTS Team Admin Meeting for whole-group discussion.

  4. Coordinate gathering input, feedback, or buy-in (as-needed). Some features and functionality aren’t a clear-cut “yes” or “no”. In these scenarios especially, LTS reaches out to stakeholders, power users, recent ticket openers, or established campus committees to get feedback and discuss the pros and cons.

  5. If there’s hesitation about any features / because there are likely features upper leadership at the university will need to weigh in on, LTS will facilitate information-gathering or meetings to get input or guidance

  6. Write or edit necessary documentation.

  7. Communicate the change. The method and timing of communication depends on many factors, mostly: how are users impacted, what types of users are impacted, when is the change automatically happening, etc. Some feature updates have no visible impact to any users, so communication would be small or just to Help Desk staff as a heads up, whereas other feature updates are overhauls of systems and require communication to all of campus: students, staff, and faculty).

If you have heard about features (in existing, supported tools) and want to know if they're on/off/etc, open up a ticket to route to LTS for discussion.

You can also submit Instructional Technology Pilots requests year-round.