Building Out Change Tiers in Enterprise Applications

In February, EA established 4 Change Tiers to help drive process and documentation rigor based on the risk (impact and complexity) of the system change (click here to read an overview of the EA Change Tiers).

Over the last few months, we’ve been working to add more structure and detail to ensure that our project and development teams can effectively utilize these tiers to scale their work based on the risk of change.

Tracking the Change Tier

EA uses JIRA to track our in-progress project work. However, not all changes are due to project work. Change due to customer request or a break/fix may only be tracked in ServiceNow. We decided to track the Tier level in both systems (since project work spends the majority of its time in JIRA and is only in ServiceNow during implementation, when the change request is made).

For JIRA, we created a custom label (EA-T2, EA-T3 and EA-T4). We can use this label to create various dashboard and reports. Also, the Tier can be updated if the impact/complexity evaluation changes as the project progresses.

For ServiceNow, the team created a standard naming convention for Change Requests that allows us to populate a dashboard that our Production Support team can use to examine upcoming changes.The EA naming convention allows us to tie the change to the JIRA but using the JIRA number as well.
* EA-T2 EA-xxxx –change description OR EA-T2 –change description (for non-projects)
* EA-T3 EA-xxxx –change description OR EA-T3 –change description (for non-projects)
* EA-T4 EA-xxxx –change description (it is not anticipated that break/fix or requests would fall into this tier)

Domain-aligned Tier Details

One of the insights that led to the creation of the EA Change Tiers was that different systems had different inherent impact and complexity. Therefore, rather than having the change type (sql vs. non-sql) drive the tier, we needed to have risk (combination of impact and complexity) drive the process. But this left the teams with a lot of ambiguity to navigate. How can we ensure that the teams were evaluating risk consistently with so many factors to consider?

Over the last few months, we’ve analyzed system changes by domain with both the project teams as well as key resources within our production support team, to create examples that can be referenced (and revised or added to). The discussion allows us to create common understanding of the tiers. And each domain has a confluence page to reference and maintain with key examples to keep the information and analysis available for review.

* A&D Domain Tier Examples
* HR Domain Tier Examples
* PhyOps Domain Tier Examples
* Research Domain Tier Examples
* WUSM Domain TierExamples

Coming Soon: Student, Enabling Apps and Finance.