Submitted by Jennie Franke
Enterprise Application (EA) offers support for a wide range of applications across the university. Our relationship and the services we provide for each application will vary.
- For most applications, the business has very limited IT knowledge or expertise on the application setup. In these scenarios, we provide services from scoping and requirements through detailed testing and implementation.
- However, for some systems, the business may take responsiblity for requirements gathering, testing and even support desk functions. Yet, the technical work sits within the EA department.
- For other specific projects or systems, the technical work may fall outside EA and be performed by Student Technology Services (STS), Vendor Application Management (VAM) or another group.
In both the last two scenarios, we need to consider how “sub-contracting” impacts risk management and our tiers.
EA as a sub-contractor
In order to be responsive to our customer needs, we look to use WashU IT and University resources as effectively as possible. In some cases, that means partnering with another team (such as STS, VAM or even a vendor) to complete work where the skill set or resource capacity is not available within EA. In these cases, we “sub-contract” the work to another team. However, EA is still responsible for the overall delivery to our customer.
In this scenario, EA is responsible for the change, we are responsible to adhere to Tiers and manage risk on behalf of our customers. Please complete the risk analysis and define the appropriate tier – EA Change Tiers.
EA managing a sub-contractor
There are a few applications that are supported by EA, but our support is limited to just technical execution and implementation. In other words, we are the “sub-contractor” for the other team. In these scenarios, the other team (such as the Service Management Office (SMO) or a departmental IT team) is responsible for the change and managing the risk associated with that change. In these scenarios, EA would evaluate just the piece that they are responsible for delivering, and not the overall change impact (to business process, managing communication, training, etc.).
In some cases, this may result in the change aligning to Tier 2 (due to the change risk and system support primarily being managed outside of EA vs. the technical risk which would be managed within EA). In this scenario, we cannot be held responsible for creating the deliverables to mitigate a higher risk (due to complexity and impact) as is outlined for Tier 3 or 4.
As best practice, be sure to include links to the request details or requirements, as well as any testing or approval content, even if it lives outside the EA JIRA or ServiceNow tools. These links should be included in the appropriate tracking system based on tier – ServiceNow and/or Confluence. Please remember, that even with Tier 2, a ServiceNow Change Request is required.
If you have any questions about which tier your change fits into, reach out to your manager, or Matt Vore and Carrie Maynard, as early as you can so that they can help you prepare for Deployment Gate and CAB