“Legacy” is the term IT leaders commonly use to distinguish the older parts of their technology portfolios from more emergent, “modern” systems.
But given the disruptive changes we’re seeing, more leaders are asking whether the real legacy problem they have is their organizational model and workforce strategy. We’re beginning to see a number of restructuring and re-organization efforts gain traction, along with questions as to whether there’s a single right model for the future.
Many Applications leaders are looking to “modernize the applications portfolio”, but the best companies are actually looking at modernizing the applications function. Simultaneously, Infrastructure leaders are facing a challenge of growing complexity that is putting Infrastructure’s future responsiveness at risk.
The best companies are pivoting Infrastructure investments to continue to improve responsiveness and position the function for future value delivery.
Both of these approaches will require a certain amount of restructuring. The track record of restructuring efforts, however, suggests that the best approaches are more about concentrating on the journey, rather than attempting to nail down the destination upfront. We’ve put together the checklist below to help guide you through this process:
Are we sure the challenges we’re trying to address are rooted in organizational design? Restructuring or reorganization can be the proverbial hammer in search of a nail, and can miss other root causes of organizational performance challenges.
The immediate danger is that leaders can burn resources and (potentially) put employee engagement at risk when restructuring isn’t the critical need. How do you know when restructuring is the right solution? Run a diagnostic exercise—typically, a structured set of questions you can run with your leadership team—to determine whether performance challenges are a matter of organizational structure, strategy, talent, rewards and recognition practices, or business processes.
If the answer is organizational structure, have you tested alternative solution hypotheses? Even when the challenge is accurately diagnosed, the development of solutions can get quickly derailed by organizational politics —in place of vested interests, we need a way to depoliticize and test alternative approaches before landing on a solution. The key is a two-stage value-chain or workflow mapping exercise.
In the first stage, the leadership team can collectively map a simplified value chain for the function as it presently exists—participants should identify all the activities they own or participate in, without associating those activities with a position or name. In this stage, the goal is simply to surface process strengths and opportunities for performance improvement.
In the second stage, the leadership team should simulate the value chain as it would operate under different organizational models. “Simulating” can be a matter of tracing how different project types would run through a value chain of activities. In this stage, the team can identify which proposed organizational model works better, in terms of having the fewest bottlenecks, least amount of role redundancy, and other goals identified for the restructuring effort.
Are our proposed solutions driven by technology need, or business requirements? The data from the CEB is clear: teams that organize primarily around technology platforms tend to be less responsive and less confident in their ability to sustain responsiveness than teams that organize around business requirements or outcomes.
Have we involved our customers (and other key stakeholders) in our solution development process? To the points above, diagnosis and testing should reflect challenges and requirements as articulated by customers and stakeholders, best gathered through an interview and/or survey process. Consider, for instance, including one or two high-potential employees, a key customer, or other outside stakeholder in the workflow mapping exercise outlined above.
Do we know what our solution means for talent requirements, and are we supporting staff through the transition? Especially in the current technology environment, restructuring is both prompted by and will demand changes in the workforce—whether in terms of bringing new roles into the organization, or changing the skills and responsibilities of current roles. Naturally, this raises the premium on change management planning—something that more than 60% of organizations cite as the most common cause of restructuring failures. What’s key here are three things.
First, a framework for understanding which skill needs are likely to diminish in importance in the new model, which are likely to increase, and what that implies for role consolidation or role creation. Second, a clear set of vetting questions to determine which staff should qualify for new roles. Third, a change management strategy that focuses on the most critical node of potential resistance in the organization—the line leader.
Do we have the right success metrics? Restructuring efforts need to grade themselves by two yardsticks: key business metrics (e.g., operating expense, customer satisfaction, etc.) related to the initial reason for restructuring, and human capital metrics that look at restructuring’s engagement and productivity impact.
The latter are often overlooked, and often not measured until it’s too late. Frequency is essential. Consider adding “human capital indicators” (e.g., absenteeism rates) that can be tracked throughout the restructuring process and which offer warning signs for potential disengagement.