No organisation would intend to invest in rework as part of a software development project, beyond allowing for a contingency. No team would be tasked to get things intentionally wrong first, and then spend time and money trying to get things right. Instead, an effort would be made to set up the delivery side of the project as well as possible to allow the software engineers to release a quality product on time and on budget.

However, when it comes to legacy modernisation projects, there’s another kind of rework – let’s call it ‘cultural rework’ – that organisations often seem to accept as an inevitable part of their investment. At least, that appears to be the case if we judge many organisations by their actions. Over the years, I’ve seen insufficient attention paid to the human and cultural aspects of legacy modernisation initiatives, leading sometimes to major project resets or, in the worst cases, to project failure.

Why legacy modernisation projects are different

Legacy modernisation projects are different from greenfield software projects because they involve significant human and cultural shifts in an organisation. You might say that they involve a lot more emotion than a standard software project, including concerns around job security, fear of the unknown, and anxiety about having to learn new skills. I’ve seen this aspect of projects treated as a second-order priority, with leadership sometimes taking the attitude that people will either have to like it or lump it. However, when people refuse—whether actively or passively—to accept a modernised system, there can be big impacts on productivity, and the return on investment (ROI) in the project can be diminished or obliterated.

I know from experience that it’s possible to get it right first time and avoid this ‘cultural rework’. For example, I worked on a legacy modernisation project for a household-name business that understood the importance of managing the human and cultural aspects of the project. They invested time and money to ensure that people understood and bought into the change, and felt represented throughout the modernisation process. The result was a contented workforce and a strong ROI.

In this blog post, I’ll look at some of the main cultural, team and human challenges that arise on legacy modernisation projects, and how they can be tackled – and in each case, the positive steps I’m going to recommend are borne out by experience.

Setting a shared vision

Things often go wrong from the start. I’ve seen legacy modernisation projects begin without any clear objectives beyond replacing the old system. Legacy systems often have tendrils running throughout an organisation, and yet I’ve seen organisations take a damagingly myopic view of how extensive a project’s stakeholders can be. Sometimes, politics at the top can exacerbate matters further, with contradictory C-suite priorities causing tension and confusion around project governance.

To have a real chance of success, legacy modernisation projects need a clear vision which is bought into, championed and consistently communicated from the top down and, vitally, across the organisation. This vision must be inspiring and it should articulate why the change matters in terms of the benefits to the system’s users and the organisation’s customers. It must provide reassurance that people will not be left behind on the modernisation journey, but instead will receive training and support as part of the change programme.

The vision must remain the project’s ‘north star’ for the duration, underpinned by unified governance that keeps everyone focused on the direction of travel and resists the temptation of scope creep. The executive sponsors must be visibly engaged and accountable for the project’s success, so that everyone accepts the authenticity of their commitment.

All of this may sound like common sense, but it’s surprisingly rare to see. Those organisations that invest the time and effort in setting up these solid foundations are more likely to be rewarded with project success.

Understanding the impact

As important as a vision is, we humans need things to be tangible. Uncertainty makes people anxious, and yet I’ve seen legacy modernisation teams operate in relative isolation, not keeping stakeholders involved in or informed of what’s changing and why. With this kind of project, opportunities will often be taken to streamline existing processes, but sometimes without properly engaging with stakeholders who may be expecting a like-for-like replacement. Meanwhile, software engineering teams can lose motivation if they’re burning through a backlog without a clear sense of the value they’re delivering.

Colleagues abhor a vacuum, so it’s important not to let one form. For example, setting up and managing a RACI matrix (RACI stands for Responsible, Accountable, Consulted, and Informed) will ensure that stakeholders are as involved or informed as they need to be, and will minimise the space available for concerns or doubts to creep in. If your project aims to improve processes, representative stakeholders with in-depth knowledge of the as-is processes should help shape the new processes; a key benefit of this is that those stakeholders will become trusted advocates of the change.

The shared vision I described above will help keep software engineers motivated, helping them understand what the system does, who it serves, and the business value it delivers. However, this needs to be reinforced by investing time and effort in regularly gathering and sharing feedback from end users to provide a tangible sense of the real-world impact of their work.

Where possible, sharing actual business outcomes will strengthen motivation further; for example, the household-name business I worked for was able to demonstrate to the delivery teams the direct relationship between the changes they were making and the business’s ability to expand operations. Of course, as important as it is to celebrate achievements like these with the delivery teams, it’s equally important to share success stories across the organisation to reinforce buy-in for the positive impact your project is making.

Managing team dynamics

On any large legacy modernisation project, multiple delivery teams will be in operation – perhaps a mix of onshore and offshore, and sometimes with in-house teams working separately from third-party consultant teams. Opportunities proliferate for silos to form, born out of different working styles, cultural differences, and poor communication. Teams from development, infrastructure, and business domains often speak different languages and have different working styles, which can cause misunderstandings and friction. On one project, I encountered passive resistance from offshore teams because they feared that the legacy modernisation project would do them out of their jobs, and this was inevitably made worse by the remote nature of the collaboration and communication.

Again, it’s important to set things up right from the start in order to avoid cultural rework. First things first: team composition matters. It’s important to bring together teams made up of people with different personalities that complement each other, rather than clashing, and to ensure that everyone has a clear role definition. Conflict is inevitable, but you can plan for it by establishing structured conflict resolution mechanisms from the outset. Fostering the right culture is vital – people need to feel safe to raise concerns, admit mistakes and suggest changes. Trust is also essential; in the case of the offshore team I mentioned, I went the extra mile – or rather, five thousand miles – to go and meet the team face to face so that we could work through their concerns together and establish trust.

All of the above underpins good collaboration which, in turn, is supported by good communication. It’s important to be intentional about this, deciding which tools and channels will be used across the teams for communication and for knowledge sharing, and agreeing on some shared terminology that is understood by all. Remote teams should never be excluded from key project meetings, and so it’s important to agree the schedule for these across the teams at the beginning. In my experience, this is usually possible, even with globe-spanning teams, without people needing to be at their desks in the wee small hours of the morning.

De-risking your investment by getting emotional

Obviously, a short blog post can’t provide comprehensive advice on how to manage stakeholder communication and team dynamics on a software delivery project. But I hope I’ve conveyed how critically important it is – particularly with legacy modernisation projects – to factor human emotions and organisational culture into your project planning and execution.

As I said at the beginning, I’ve worked on several legacy projects over the years. On the less successful of those, it’s been dispiriting to see time and money wasted, and the amount of frustration and anxiety that can result from insufficient attention to the cultural and human factors. This is especially the case when I know from experience that it is all largely avoidable if the project is approached in the right way.

It’s now something of a cliché to say, “culture eats strategy for breakfast,” but that doesn’t stop it from being true. If you’re setting up a legacy modernisation project and looking for the best way to reduce risk, make sure you invest time and resources into ensuring that the human outcomes of your project are as positive as the technological ones.