Submitted by Jennie Franke
In supporting over 100 applications, EA spends quite a bit of time managing upgrades. The systems that we support vary from out-of-the-box implementations of straightforward solutions (such as DocuSign) to complex, integrated and highly configured solutions (like the Research Management System – RMS). Despite this range of complexity, we identified the opportunity to apply lessons learned and common themes to help improve how we manage upgrades and have created the System Upgrade Playbook.
System Variables
The first thing that we identified was that although there was a large variations in how we support these systems, there were common variables that needed to be clear to ensure a smooth upgrade plan could be created. Based on that, the system administrators responsible for our systems have created a Variable Matrix that outlines the data that the team will need to understand when putting together a plan. Variables include:
- Vendor Name and maturity
- Upgrade type (forced/mandatory or opt-in)
- Non-prod environments and typical use
- Technical support skills required
- User Groups
- User focused product pages
- User Training
- UAT resources
- Regression Scenarios
Determining Tier for Upgrades
Enterprise Applications has been evaluating risk criteria to determine Change Tier for production changes for more than 6 months. These change tiers help us determine the appropriate level of documentation and process necessary to ensure we are managing the risk associated with the change. Upgrade project/changes will need to flow through the same Risk Evaluation process as other EA changes.
- Applications implemented “Out of the Box” may have a lower risk because it does not have customization and may not include integration. However, the vendor maturity, user impact, number of users and other factors need to be considered.
- Applications with customization and/or integrations will fall into Tier 3 or 4 which require a higher level of documentation.
Project Plan & Process for Upgrades
The general activities in an upgrade project will align with a standard project plan. However, there are some common key dates to establish for upgrade projects
- Vendor Release Date – when is the updated product available for WUIT to engage in impact analysis and testing
- Testing Timeframe – establish and coordinate testing activities with both WU testers and vendor
- WU Implementation Date – establish when upgrade will be implemented into production, taking into account business activities, team and vendor availability
Once these dates are established, the team can begin filling in additional activities:
- Communication dates
- Coordinating testing activities with stakeholders and other IT departments
- CAB and TTO Activities
Upgrade Artifacts
Because upgrade projects align with EA Change Tiers, the required artifacts will align as well. However, some artifacts require special consideration because the change is often driven by the vendor rather than a business request. And since upgrades are based on vended products, the design document and testing, will be approached differently than a standard enhancement or custom development.
This page in the EA confluence space outlines these considerations and how to deliver value-added documentation for system upgrade projects – https://confluence.wustl.edu/display/EnterpriseApplications/Upgrade+Artifacts
Vendor Management and Escalations
Although an extensive topic with more consideration than upgrade efforts in particular, we’ve identified some best practices that will assist with managing upgrades by knowing how to engage with vendors, and escalate if needed. Building a relationship with the vendor can ensure that when issue or questions arise, the vendor is responsive. Some best practices include:
- Engaging in regularly scheduled meetings (weekly, monthly or quarterly – depending on the system).
- Agenda typically includes current state, future state and any pain points.
- Discuss licenses as well, if applicable
- Participate in system User Groups and/or conferences
- This helps provide contacts both with the vendor as well as peer institutions
- With peer contacts, you can work to influence vendor change
- Familiarity with vendor SLA/SLE, priority definitions and support processes
- These can vary across systems and vendors
- Be sure to engage your AD or IT Admin for contract details if you are not familiar with the vendor SLA/SLEs
If you encounter issues with vendor responsiveness, not adhering to SLA/SLEs or other concerns that require action, please engage your resource manager who will help ensure the proper visibility to address the issue. Also, be sure to clearly state the concern, the impact and the expected resolution (including time expectations if appropriate) when escalating issues to ensure clear expectations.