• Phone
  • Contact us
  • Locations
  • Search
  • Menu

share

  • Add this article to your LinkedIn page
  • Add this article to your Twitter feed
  • Email this article
View or print a PDF of this page
.

Building a case for change in legacy environments

Nilesh Chandra, and Craig Rintoul 
PA Consulting Group 
Align Journal
1 March 2008

The success of any initiative depends on identifying the right group of stakeholders and working collaboratively to define the scope.

Many of today’s businesses run on legacy systems - business applications that have been enhanced, patched, modified, and joined together over many years to fit evolving needs. Usually, these systems are embedded in the business processes of organizations.

It’s no secret that legacy systems pose problems - from both a business and technical standpoint. For users, these systems lack functionality, and data, which is often hard to enter and retrieve, is disconnected from and inconsistent with other data sources. Business processes have evolved in a convoluted fashion to work around system limitations and are manually intensive. In addition, the time for any business change dramatically increases because systems aren’t agile enough.

For IT, having an evolutionary system architecture often leads to system redundancy, a multitude of point-to-point interfaces, and added complexity that makes it harder to understand or change systems when needed. This results in a lack of understanding and effectiveness of legacy systems and processes, an increasing number of manual workarounds, and increased risk.

As advocates for change often find out, there are many barriers to a successful legacy transformation initiative. Stakeholders with an interest in maintaining the status quo often resist change and business leadership doesn’t fully realize the magnitude of the problem posed by legacy systems, often because they get the reports and results they need but don’t see the effort that goes into producing them. Business leaders balk at the price tag associated with any attempt at major change and espouse the refrain: “This old technology has worked well for us in the past. Why do we need to change it if change is so expensive?”

If approved, change initiatives also face the risk of getting caught up in the latest technology fad, and may be adopted without fully ensuring that it will address long-term business needs.

How can advocates successfully build a case for change and how do they select the right solution to the problems they face?

This article focuses on how change advocates can:

  • Effectively assess the current state of business operations

  • Determine if change is truly needed and what it looks like

  • Build an essential case for change, if a change initiative is necessary.

You should follow a structured approach that assesses the current state of the organization with a three-step process that will help engage all stakeholders, drive consensus on the need, and build a case for change. This methodology must not be tied to a prescribed outcome but to the best solution for the business - even if that results in recommending little or no change. This process involves:

  • Discovery: determining if the case for change is compelling enough to deem it essential

  • Design: preparation in readiness for change

  • Delivery: making change happen.

This article focuses on discovery.

The discovery phase comprises three key steps:

  1. Mobilize

  2. Diagnosis

  3. Visioning.

Mobilize: The success of any initiative depends on identifying the right group of stakeholders and working collaboratively to define the scope. It’s important to ensure that, to be useful and meaningful, the scope covers the breadth of problems the organization faces. This also is the time to mobilize resources, communicate goals and scope of the discovery process, and set up a governance model and organization.

Diagnosis: Every organization is different, as are their challenges. So it’s critical to begin this exercise with no preconceived solution. Diagnosis involves building a sufficiently deep understanding of the “as is” situation, including people, processes, technology and data. This understanding is the key to developing and agreeing on high-level decisions for process and technological improvements.

A deep understanding of the business can only be built by talking, via interviews, workshops or both, with a diverse group of users and the IT staff that support them. These interviews help reveal the culture, attitudes and barriers toward change. This ensures that any solution is practical for the unique situation of a particular organization. It’s important to involve senior executives to gain their support and guidance.

A variety of tools can be used during the diagnosis phase, including a 'rich picture', a visual representation of an organization’s processes, people, technology and data on a single (often large) piece of paper. It provides a compelling visual representation of the complexity arising from legacy system architecture, with its multitude of interfaces, hand-offs and manual processes, and highlights areas for potential improvement.

To build momentum, the diagnosis phase should be performed in a compressed timeframe. Depending on organization size and scope, the diagnosis typically takes four to six weeks. While this inevitably involves extra effort and precludes use of a larger team, this extra effort is worth it. The output is a rich picture identifying improvement opportunities and demonstrating a good understanding of business complexity. A well-developed and presented rich picture can convince skeptics that change is necessary by highlighting the complexity of operations and opportunities for process improvement.

Visioning: Visioning is a collaborative exercise to develop a compelling vision for the future. The process energizes the organization and focuses on meeting business need at all levels. Major stakeholders must be involved to ensure buy in and identify each perspective. The vision highlights a desired state and the metrics and measures of success. The desired state must align with the organization’s goals and objectives and the metrics and measures must have quantifiable, tangible benefits.

Once prioritized, a set of recommendations for addressing improvement opportunities are developed. In parallel, a high-level benefits roadmap for the design phase is built and incorporated into the case for change presentation.

The benefits roadmap helps to:

  • Map and assess the timeline for key process change or IT improvements

  • Identify potential conflicts or dependencies between changes

  • Determine key benefit milestones arising out of the diagnosis work.

Toward the end of this stage, a case for change workshop is held where the future high-level vision is reviewed. Subject to agreement with stakeholders, there’s an opportunity to accelerate quick win improvement opportunities and build the business case to substantiate major change.

The outcome is agreement on the improvement opportunities, a business case for major change, and the plan for taking the design of these to the next level - paving the road to implementation and a belief that change can be effectively achieved.

At the end of the visioning exercise, change advocates have:

  • A set of improvement opportunities and an overall solution, with smaller business cases detailing the high-level costs and benefits of components of the solution

  • A case for change presentation for a long-term solution that brings it all together for the senior stakeholder team

  • A high-level benefits roadmap for successful implementation.

Conclusion
Like any major change program, a legacy transformation initiative requires a well-articulated business case that clearly demonstrates benefits and a clear, achievable roadmap for success. This case for change methodology can help an organization achieve those objectives. Clearly linking the vision to organizational objectives helps ensure that the change implemented is rational. Including a diverse group of stakeholders through the diagnosis and visioning process can help convince skeptics of the need for change and ensure buy in to make it successful.

Craig Rintoul is a managing consultant in PA Consulting Group’s IT Consulting practice.  He has delivered projects across a range of disciplines, including outsourcing, IT service delivery and management, IT infrastructure implementation management and application development.

Nilesh Chandra is a consultant in PA Consulting Group’s IT Consulting practice.  He has extensive experience in working in the design and architecture of large scale enterprise systems and leading teams to manage complex technology platforms.

NEWS UPDATES

Sign-up to receive company updates and press releases by email or newsfeed:

SIGN-UP

 

   
Corporate headquarters
123 Buckingham Palace Road
London SW1W 9SR London SW1W 9SR
United Kingdom
Tel: +44 20 7333 5865 Tel: +44 20 7333 5865
contact us now

By using this website, you accept the use of cookies. For more information on how to manage cookies, please read our privacy policy.

×