An enterprise risk platform supports critical workflows for more than 100 users in my department and thousands across the firm. Over time, platform friction was handled through individual support requests, manual workarounds, and downstream tools. When I took ownership of the platform for my department, that friction surfaced as 60+ statements describing what users wanted changed. Working through each individually wasn’t going to solve much. It was determining what the problem actually was, whether it should be solved, and defining the right solution.
This case study focuses on my role, approach, and decision-making process. Examples have been generalized, and proprietary business details have been omitted.
The backlog was full of solutions. Add a field. Change this permission. Remove this record. Modify this workflow. So I started working backward. What was the user trying to do? Where was the workflow breaking? Who did it affect? What else depended on it?
That changed the backlog pretty quickly. Some requests were really the same problem. Others contained a few different problems bundled together. And some things that looked like platform limitations turned out to be existing capabilities, process issues, external dependencies, or work already happening somewhere else.
I started by looking at how many users a problem affected and how much time it could save. Then I considered business importance, dependencies, shared-platform impact, technical constraints, and related work already underway. I used three questions to work through the defined problems:
Which problems matter most?
What’s actually causing the problem?
Where should the solution live?
Now we had a way to decide what needed attention or more investigation, and where each solution actually belonged.
Here are three examples.
External Data Dependency
Existing Platform Capability
Process & Adoption
I explored API-based automation for repetitive work. While technically feasible, implementation required additional consideration around permissions, governance, and change tracking. I connected with adjacent teams to establish the conditions that would make it safe to use.
A solution could touch the platform, data, reporting, internal tools, or processes, often across different teams. Because I worked across that system, I could trace those connections and understand what each change would require.
From there, I brought in the people needed to move it forward. I worked across users, technology teams, reporting and data teams, our vendor, and leadership to build solutions.
How do we improve this platform?
How should the platform, data, tools, and workflows work together?
In the first four full months after kickoff, we saw a decline in average monthly support ticket volume compared with the pre-project baseline. It’s still an early signal, but an encouraging one. Recurring problems were starting to be addressed more systematically, along with shifting how the department operated:
What began as 60+ platform requests became a repeatable framework for deciding what should change, where the solution belongs, and how to implement it.