Legacy System Support Decisions Require Collaboration
Legacy systems are a challenge for all companies, especially those who grow through acquisition or need to focus on immediate profitability after a merger. Modernizing and consolidating systems is often left out of acquisition timelines. Unfortunately, this often leaves IT with a patchwork of legacy systems to manage and a lack of partnership between IT and the rest of the business.
While working at a medium-sized company in the Seattle area, my group was left to manage a setup just like this. A growth model structured around acquisitions, combined with a lack of system ownership within business groups, left IT to manage a patchwork of nearly a dozen separate Finance, HR, Payroll, and Sales & Marketing systems across several business divisions. Our IT team of three was left with the challenge to integrate, administer, and patch this network of systems on our own.
Taking Ownership
The IT team knew these systems were designed to help the business function consistently and efficiently, so we set out to do everything in our power to provide the business with maximum value from these systems.
However, without any direct partnership between the IT team and the business, four issues arose.
When an issue was discovered, IT had no clear escalation path to follow to find users to help troubleshoot and design workarounds to resolve these issues. We were unable to get any help with testing a time-critical workaround and left entirely on our own to first find and then communicate to all impacted users. Since IT alone was testing the fix, two additional risks arose: That the potential fix may not resolve the entire issue, and that the fix itself may negatively impact another group after it’s implemented.
IT had no single contact for planning patches and system outages. Again, we were left to find anyone who would be impacted by these projects. Generally this wasn’t an issue, but special projects or new groups unknown to IT were at risk of unexpected impacts from these outages. Whenever this happened, the project would need to be immediately halted, reverted back, and then re-planned; this led to a lot of extra planning for IT as well as the business units that needed to work around the outages.
Required patches and system upgrades often release new, important, and time-saving features, but they can only be implemented if IT takes the extra step to notify the business of a possible enhancement. Since we didn’t see all of the operations of the business, we didn’t always know that a feature would be beneficial. As a result, these changes would go undiscovered and unused for long periods of time after release – if they were utilized at all.
Suggested upgrades and changes would come into IT from any user. There was no “owner” to triage and prioritize these suggestions. We had to independently prioritize these suggestions based on whatever information we had. This led to resentment among business users who were told “No.” They often misinterpreted the decision to not implement a change as a statement of the business value of the suggestion, not simply a constraint due to resource availability.
Empower Business Users
Based on this experience, as well as previous IT roles I’ve held, there is a two-step solution to the types of problems I’ve described.
First, don’t wait for a large-scale, business-wide financial transformation to motivate a consolidation of IT systems. This certainly provides obvious advantages such as consistency in process, financial/operational controls, and reporting. But there’s a more direct solution: Assign a product owner to each system within the business unit that utilizes that system.
This role is responsible directly to the rest of the business team for the functionality of the system – partnering with IT to make sure available IT resources are spent on integrations, feature enhancements, and other improvements that will provide the greatest value to the business itself. This role is also responsible for triaging and prioritizing the product backlog – the list of proposed system changes and enhancements, taken from everyone in both the business and IT.
Assigning control within the business provides the necessary expertise to discover where new features may be of value. In addition, business team members have a direct contact within their own group to discuss suggested improvements. Keeping these discussions within the team itself leads to a greater sense of ownership in the team.
Second, recognize that there’s a cost associated with each system that must be maintained. Each system requires time for administration (configuration, user setup, regular patches) as well as effort to troubleshoot and maintain integrations.
One IT administrator can only effectively administer a few systems at a time – and, in a perfect world, would only be responsible for one. Adding one more system to an administrator's plate means they apply a lower level of expertise to each subsequent system. That lack of expertise may lengthen the time it takes to resolve issues, which increases the risk to critical business operations.
This second step can be a challenge for some businesses, as business leaders often don’t understand what it takes to manage legacy systems from the IT side. That’s where the first step comes in play. Having product owners within the business can help put this cost in perspective, as business leaders see the time it takes their own team members to effectively manage the legacy system and its associated backlog.
With this understanding, IT optimization can shift from something that business leaders decide to deal with later to something that becomes a priority – and is much easier for a resource-strapped IT team to manage. If you face similar legacy support resource and planning decisions, contact Healthcare IT Leaders for expert advice and support.
Senior Consultant Ryan Green, PMP is an experienced Project Manager and Systems Admin with experience implementing and managing a wide range of enterprise business applications.
