Most technology enthusiasts have probably already glanced over the much-cited McKinsey research according to which 70% of change-instigating endeavors are unsuccessful when it comes to reaching their goals. Therefore, experienced software teams engaging in software modernization do not underestimate the odds that loom over these large transformative projects. What do organizations consider as holdbacks that could prevent them from modernizing?

What would prevent you from modernizing your organization’s flow with new technologies?
Source: The Annual Software Trends Report 2020/21 highlights

The above graphic shows that digital assets’ modernization hardly consists of merely a software upgrade. As a matter of fact, it encompasses a wide range of interdisciplinary aspects, the least of which are team-related, organizational, and way-of-thinking areas. So much so that the whole revamp process may even be compared to maintaining a tumbling tower made of many constitutive blocks. If you take out or mishandle one block, the whole construct may become shaky or even fall down, taking other building blocks down with it and undermining the entire project.

That being said, how do we know that a given modernization endeavor has been, in fact, a failure?

What is a failure in software modernization?

According to Chris McMasters, the CIO of the City of Corona, “(...) if we’re not providing the outcome the end-user expects, that’s failure”. In fact, a failed digital revitalization means that the project’s goals have not been reached. While the aims may be highly diversified and relative to a given business, the ability to meet these objectives is what actually predestines you for success. They are typically established at the very beginning of a project during the pre-development phase. These aims constitute the very reason why your organization embarked on the modernization journey in the first place. The goals are rooted in your business, and thus furnish your stakeholders with a concrete value measured by metrics, provided that they are met.

Due to the multidimensional and complex nature of digital upgrades, it is reasonable to assume that there are usually many reasons that contribute to a failed software renewal project. Therefore, we should consider these factors as a whole – a set of circumstances that may work to your advantage or backfire, depending on how they are handled. So what are the possible scenarios that may happen here?

Reasons for failed software modernization projects

It goes without saying that every modernization undertaking is different, and so are the reasons for its possible failure or success. Sure, the project may not come to a realization due to limited budgetary perspectives, but, as the statistical data shows, software revitalization endeavors usually backfire due to factors other than money. In fact, software modernization research, case studies, and tech leaders’ testimonials show some recurring failure-contributing patterns CIOs should specifically steer clear of when upgrading software. They usually include rationale that revolves around people, skills, and planning, to say the least. Let’s examine some of these warning signs.

• My people are not convinced

The fact of the matter is that the more people take part in software modernization, the higher the risk of their viewpoints clashing. As people not only implement but essentially shape such deep organizational changes, it is necessary to get them on board. In fact, non-believers can undermine the project’s success in the long term and bring down the morale of the rest of the team. Understanding the reasons behind this lack of support for the project is a must, though. Elizabeth Hackenson, the host of CIO Leadership Live states that technology is actually the easier part of software projects, whereas people and process handling are the two factors of the utmost importance.

That said, it may be the case that your team is afraid of change, and therefore is not persuaded enough to support your product’s modernization. In that case, it may pay off to open up the lines of communication and discuss the specific concerns that your people are voicing. 

It can also happen that your employees dread the prospect of losing control of some parts of the process. As studies show, people’s sense of control is a form of protection that can counteract the consequences of stressful events (such as organizational and digital transformation). Again, discussing the changes but also sharing knowledge of the process, showing its long-term benefits and more immediate quick wins for a particular group may help alleviate the feeling of embarking on an uncontrollable journey.

When fear kicks in, that big corporate change can become intensely personal

Rick Maurer, source: Reply-mc; Online Magazine for Organizational Change Practitioners

Another possible scenario is that your people’s lack of convincement for modernization results from lacking the abilities necessary to use the new software. This may also trigger a perceived lack of demand for their services. The conviction that your work has meaning for the organization’s success is one of the strongest drivers of motivation at work – one that should not be overlooked when putting your teams through the test of digital modernization. In this case, you should make sure to provide training and sketch out a development plan that will tame these anxieties and turn them into a possibility for personal growth.

There is also a risk of a rising value of group-particular interests during software modernization. To illustrate this point, let’s take a look at one of the examples of this phenomenon. The CIO Magazine describes a software modernization case where reducing the number of stakeholders resulted in setting off project participants’ concerns about losing their department-crucial functionalities in the new version of the system:

(...) people were worried they were going to lose features they felt were important to their business units

This case shows another angle from which people in your organization may fear modernization. While you might not be able to satisfy all affected parties – and may not need to in every case – it's always wise to stick to your business goals and show the skeptical audience the bigger picture of how these translate into more efficient processes of specific departments and the whole organization. Such an approach will demonstrate that you have a larger aim in mind. Besides, reducing the number of stakeholders may also limit your project requirements to a crucial minimum. If you want to learn more about the software requirements specification, read this article as well!

• We have specified the goals. Let’s move on to development as fast as we can

It is often the case that badly-set project goals may lead you astray on your modernization journey. The research by McKinsey and the University of Oxford shown below, based on 5400 IT projects, indicates that ambiguous and non-business-oriented objectives can constitute 13% of a 45% budget overrun level in failed IT projects:

Four groups of issues that trigger most project failures identified by IT executives in the McKinsey and Oxford study

Not knowing your goals may lead to business value decreasing by 56% in such unsuccessful projects, as the same research also demonstrates. If you cannot correctly identify the value of a software upgrade, how can you measure its actual effectiveness? All of these aspects are related to one another. The pending question here is as follows: how exactly does it happen that project leaders sometimes select goals that have little to do with their organizations’ business needs? As a CIO, you might wonder how to not lead your teams astray on your modernization journey. The course of the pre-development phase of digital revitalization is of crucial importance here. This stage includes steps such as project discovery, as-is system assessment, modeling, and planning. It aims to determine the business- and needs-specific goals of the project so that the solutions used in development suit these aims perfectly.

Pre-development and development stages of software modernization

For example, if we were to focus solely on revamping your system's UX, based on some functional problems being manifested there, without looking at the system's core, warning signs from users and overlooking the bigger picture, our upgrade efforts could be ill-suited and pointless. Well-selected goals should be a direct result of a thorough system analysis, a good understanding of the business, and choosing a system's model based on precise knowledge of system subdomains and their impact on various applications. Therefore, while there is no modernization playbook, sticking to the overview of your specific system will allow you to stay on the well-reasoned side. If you want to know more about the real costs of maintaining an outdated system, check out our other article!

• Our plan seems not to be working

Effective planning is often emphasized when instigating change as far-reaching as software modernization. But what does it mean to plan well? There is one specific element that goes into every good plan for your application’s revamp. It is a strategic approach to timeline preparation. In opposition to reactive planning, working out a solution driven by a strategic, long-term, business-oriented vision rather than singular, ad-hoc reactions to arising problems is key.

The earlier-cited McKinsey-Oxford research into IT project failure reasons shows that bad planning can contribute in 11% to a 45% cost overrun level of failed IT projects. When executing a good plan, it pays off to first and foremost focus on the must-haves related to the “minimal usable subset” of your system. One of the practical methods that facilitate such priority-oriented planning is the MoSCoW technique used in software development as well as business analysis and management. By placing specific priority labels on the tasks at hand, it gives a good overview of the true must-haves of your endeavor.

Another component of a successful strategic plan is effective change management. Deloitte describes a software modernization case study where badly handled transformation in part contributed to a failure of the whole project. Navigating change management so large in scope as system revitalization is indeed a challenge – not only for medium-sized players but also large organizations. Luckily, there are specific methodologies that you can use to help yourself and your team go through the process. For example, within Kotter’s 8-step model of change, there’s an assumption that you won’t be able to successfully instigate change unless you have the buy-in from at least 75% of the executive suite. The sense of urgency that allows for gathering supporters of the project helps in executing change. To learn more about the risk management process, read this article!

• We’re ready to modernize but prefer to stay on the familiar track as much as possible

Mark Billiger, the Vice President and Chief Technology Officer of Dell Services, takes flexibility to be one of the factors that drive efficient companies. Localization-independent and scalability-friendly solutions such as the cloud, do support organizations in regaining their full operational capability when suited to business goals. How to then leverage these digital enablers without leaving our comfort zones too much?

There’s no way of successfully modernizing without letting go of the fear of the unknown completely. In fact, technology leaders deal with unknown unknowns arguably more than anyone else – and it is an inseparable part of this journey towards new software. Having said that, flexibility is surely an approach that facilitates openness to change. It supports your teams’ efforts to let go of the fear and feeling of a lack of control. Companies unfamiliar with agility typically lack it already at the C-suite level. What can you do to prevent that?

You might want to explore the modern iterative management methodologies such as Agile, DevOps, CD, and fast-fail movement. They are widely appreciated by business practitioners due to the transformative power they give to projects where they are used and the phased project progress they provide. Contrary to risky Big-Bang methods, the iterative approach allows a more steady Software Development Life Cycle (SDLC).

All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner.

Mark Richards and Neal Ford “Fundamentals of Software Architecture”

Choosing a well-suited modernization strategy beforehand (at the pre-development stage) is also one of the ways to address the fear of venturing into the unknown and ensuring a smooth transition to new software. At the very basic level, software modernization usually involves choosing the right cloud architecture and moving applications to the cloud with few or no modifications to the code. This is the Lift & Shift strategy, and it helps to ensure digital modernization with minimal disruption to the application. 

Another approach to modernization involves code refactoring, necessary to move the application to the cloud. It enables scalability, adding new features, and enhancing performance with no external manifestation of these changes. Using the Augment & Refactor strategy means that the architecture of the existing application remains unchanged.

Finally, the most far-reaching and benefits-packed approach is a Complete Rewrite. While it’s the most transformative modernization strategy, you get a completely modern and future-ready solution based on a top-notch stack. That being said, such a revolution is only possible while rebuilding the application from the ground up.

The choice of a specific approach to modernizing is relative to your business; however, these strategies cover the various digital modernization needs to a full extent. Although each strategy is different, all of them provide you with a relative readiness and awareness of the road ahead.

Wondering how other companies like yours travelled the road of software modernization? Check out our SafeEx case study!

Look beyond technology

Summing up, there are a number of aspects that may factor into an unsuccessful modernization. If your team is not convinced enough to upgrade the software, there is little chance that they will widen their skills necessary for using the new system. In a similar manner, if we misjudge the modernization goals at the beginning of the project, our time, efforts, and money might be wasted irrecoverably during the implementation process. Also, if the game plan doesn’t take into account the risks related to change management and the proper time for execution, even the most enthusiastic team won’t be able to handle such organizational challenges. There are many more examples of how various aspects of a system upgrade are interconnected and influence one another. That’s the main reason why modernization endeavors are so challenging to organizations.

By and large, the interdisciplinary nature of software modernization necessitates a holistic approach to all the building blocks that may tip the scales of the upgrade’s success or failure. Therefore, as a CIO you need to consider many more aspects than merely the technology. You look to your teams to support and implement the system revamp process while allowing them space to eradicate the fear of change by fast upskilling. You dig into your business and investigate the software systems’ inner workings to inform the modernization process-related goals. Finally, you prepare your organization in advance, using the knowledge of the system’s minimal usability components to leverage time most effectively. You use modern iterative methodologies to tackle the complex revamp or hire qualified tech partners to take ownership of the process of a digital upgrade.

Looking for more modernization-oriented tips? Check out our software modernization content collection – and let our experience foster your success!