For the past two months, I have been discussing a multi-institutional approach to a Research Administration project. We have reviewed the overall purpose of this strategy, as well as the challenges for implementation. In the final article on this topic, I would like to review the challenges regarding supporting an application of this nature, which includes software updates and upgrades, along with the potential resource costs that may be required.
As we had discussed previously, a consortium or system approach is one where a number of institutions are using a centralized location for the management of their Research Administration requirements. There is a single database that is segmented appropriately so that each participating institution can have its own repository of information, secured from the rest of the consortium. The challenge that must be overcome in this instance is how to support the application once it is in use by any or all of the participating institutions. There are three areas of support concerns that need to be addressed:
- Resources
- Upgrades/Updates
- Daily Support/Training
Resources
One of the most important questions to think about at the start of the project is what resources will be required to support the system? Because the system is centralized and hosted in a single location, what makes the most sense is to have a centralized support desk. Each of the participating institutions would phone or log questions or issues into the central support desk that would then address the issues either on their own or with the assistance of the software vendor. In order for this approach to work, it would be advantageous for each of the participating institutions to have a dedicated project manager responsible for the system implementation at their facility. That one project manager would then relay the issues and concerns to the support desk and the communication patterns become much more appropriate to handle.
The other option is to have a distributed support channel, in which each participating institution maintains their own support desk and resolves their own issues or communicates directly with the vendor. I would caution against this approach for a number of reasons:
- With a centralized system, core functionality remains the same across all implementations. Having a centralized support desk allows for issues to be reviewed from the consortium level and to have the best method of resolution that suits all parties.
- If the consortium has purchased the software from an outside vendor, be careful about the licensing agreements. In the centralized model, many times the price structure is such that the software is provided to the centralized governing body and then allowed to be used at any participating institution. The license agreement may outline the need to work with only the centralized entity and not allow for the interaction with the participating institutions without additional cost
Upgrades and Updates
As new releases of software are made available, whether that is through patches or full upgrade releases, they will need to be applied to the centralized system. To have a decentralized support desk will make this process extremely difficult, if not impossible, as the software will be updated for everyone at the same time. Remember…there are core functions that are used by all participating institutions, as well as discrete functions that are only used by some. It is these core functions that must be taken into account when addressing this issue.
Daily Support/Training
In order to address the day-to-day activities that arise on a project of this nature, there is a hierarchical support structure that should be in place that I have alluded to previously. First, at the participating institution level, there should be a contact person that can assist with training and basic functionality questions. This will allow response time for minor issues and questions to be minimal and will gain the confidence of the personnel at the participating institution.
Above the institutional level contact, would be the central contact. This person(s) would oversee issues coming in from all institutions and ensure their timely and efficient resolution. This will also allow the dissemination of information regarding issues that one institution may have found while another did not. This person would be in contact with the institutional representatives to ensure the appropriate transfer of information back and forth regarding the resolution of questions and/or training on a consortium level.
I hope throughout the last three (3) months that you have found these articles to be informative and to assist you in developing a strategy for your own Research Administration project. Should you need additional information please contact Bill Kupiec, Vice-President of International Market Development at bkupiec@Infoedglobal.com.
