When you consider the drivers of legacy transformation and the financial investment required for legacy transformation projects, it’s easy to see why going it alone is not an option.
Legacy transformation is a team sport because it’s hard, expensive and can take a long time, so you need to have everyone ready to push in the same direction from the start. Organisations must involve digital teams, who can deliver new applications, technology teams, who are responsible for maintaining applications, and business or service teams, who are using applications on a daily basis. The needs and frustrations of all these groups must be considered if your legacy transformation strategy is to be successful.
Building the right team from the start is also important so everyone understands how gradual changes will help to derisk the process. This can be hard when you don’t have a history of working in an agile, incremental way. However, by explaining your intentions early on, you will give yourself the best chance of achieving a worthwhile transformation.
Digital vs Technology
In many organisations, there is a divide between teams that build new user-centric applications and those who are responsible for maintaining the critical legacy systems that day-to-day services run off.
In fact, one of the reasons legacy application issues occur is that these headline grabbing new services receive investment while the boring but critical core systems are left to gradually degrade. This is never a good strategy because new applications will invariably need to interact with core legacy systems in order to be useful. Failing to engage with the people who maintain these systems will therefore only cause issues down the line.
Just as it’s important to involve those who understand the art of the possible, the people who can give you a true warts and all analysis of the ‘as is’ state must be heard. Your IT and application support staff will be the ones who are able to add the crucial feasibility angle to any desirable idea your developers want to jump in and build.
One team, one dream
Legacy transformation needs more than just digital and technology know-how though and every strategy must start from the same point – understanding and empathising with users.
Empathy should be the driving force behind everything the team does. This will sound familiar to many, especially those who are responsible for developing new digital services with a user-first approach. What’s really important for legacy transformation is that this empathy is directed at all areas of the team, from the service or business users, to the IT maintainers and the digital developers. Each team member should understand and empathise with what drives and frustrates everyone else.
It’s important to set out like this because service teams and IT maintenance teams are often overlooked in legacy application transformation. While digital teams might have an admirable urge to get on and replace legacy technology, not involving those who have been looking after these systems for 10 years or those who know how frustrating they are to use is a major mistake.
Ignoring these insights is a particularly bad idea if an organisation chooses to follow a process of iterative legacy transformation. In this scenario, the organisation might find itself in a situation where one user group is moved onto the new application, while another is left interacting with a legacy system, waiting to be moved across at a later stage. To get this right, everyone in the organisation needs to be onboard.
Who is in the perfect team?
Building a multidisciplinary team to modernise legacy applications is important because you need to bring together people with a vision of the future and those that can actually make it happen.
Service owner – responsible for all the touchpoints involved in a public sector organisation’s service, including digital and non-digital elements.
Product owner – responsible for delivering a specific digital application as part of a public sector organisation’s service.
Technical architect – responsible for defining the structure of systems and applications, and how data flows between them.
Delivery manager – responsible for leading the agile and lean practices within a legacy transformation programme.
Business analyst – responsible for understanding the business needs of a service and how these fit into an organisation’s strategy.
Software engineer – responsible for building and delivering any new applications, as well as making changes to existing legacy ones.
User researcher – responsible for understanding user needs and how the service might be designed to meet them.
Service designer – responsible for designing all the touchpoints involved in a public sector organisation’s service, including digital and non digital elements.
Interaction designer – responsible for researching and designing the content of the service, so it helps users to complete any tasks they need to.
Support team – responsible for fixing an application when it breaks, so the service is always available for users.
Other additions – every team is different and some other people you might include are content designers, subject matter experts and performance data analysts.
As mentioned, an important driver behind building this sort of multidisciplinary team is empathising with a whole range of internal and external users from the start. Only by bringing all of these elements together at an early stage will you be able to develop a legacy transformation strategy that is desirable, feasible and viable.
Don’t forget your senior stakeholders
By building a multidisciplinary team that helps you to understand the ‘as is’ state and the art of possible, you are reducing the chance of unforeseen issues halting future progress.
To reduce this risk further, you should also ensure your fellow senior stakeholders are on side too. Firstly, they need to be shown why such a wide range of employees must be involved in legacy transformation. Secondly, they need to be convinced why a derisked legacy transformation strategy based on small, incremental changes makes sense in the long run.
Taking an agile approach to modernising applications involves failing fast but doing so in a way that can be rolled back quickly and easily. In this way, rapid progress can be made while derisking the sort of legacy technology disaster that others have experienced.
The issue is that senior stakeholders are used to being presented with big bang transformations, where they have a deadline to aim for, after which (they are told) all their problems will be solved. Even though history tells us these are the legacy transformations that often fail and cost huge amounts of money to fix, you need to ensure senior stakeholders understand this early on.
If not, your piecemeal strategy is in danger of getting to a stage where it looks like a mess of parallel changes being made to systems with different user groups and no end in sight. If you’re not careful, your sensible and derisked agile transformation could end up appearing like you are failing to plan ahead.
Having head cover from a CEO, COO or Head of service who understands the bigger picture, and who can back you up when you’re in the midst of a complex transformation programme, might be the difference between failure and success. You should therefore be engaging and educating them on the risk reduction benefits of your approach as early as possible.
Working together from the start
Ensuring you have the right team in place to work on legacy application transformation will seem hard at first, especially if your organisation has traditionally been siloed into teams with specific, ring fenced responsibilities.
However, it might also be the most important step you take in the whole project. It will allow different areas of the organisation to see how legacy transformation can benefit them and allow you to develop a strategy that ensures it does. It will also establish a collective momentum that can help you through the inevitable hiccups that occur along the way.
Crucially though, it sets the tone for the way you will work. It establishes a foundation of empathy within the project and shows your organisation that previously overlooked areas will play a crucial role in legacy application transformation.
This blog post is part of a series that covers modernising legacy applications. This blog post has been co-authored by our CTO Luke Morton, Senior Technical Advisor David Winter, Technical Consultant Ben Pirt, and Content Consultant Joe Carstairs. Keep an eye on the blog for my next post discussing the mapping of organisations and applications. We are always trying to improve our blog and we’d appreciate any feedback you could share in this short feedback survey.
If you are interested in learning more about this topic, our team has released our ‘Modernising Legacy Applications In The Public Sector’ e-book which will empower you to define and implement the right approach for your organisation to make legacy applications a thing of the past. Download a free copy here.
