30 Aug Causes and consequences of unsuccessful IT deployments
It is August 2017. One of the leaders of the financial world – Provident Financial – loses over 66% of their value on the London Stock Exchange in just 1 day. The president of the company immediately steps down. Financial markets are going crazy.
Almost exactly one year later, the giant of the food industry – Lidl – loses over 500 million euros due to a failure of an eight years long IT project. The economy analysts are wondering how this will affect the condition of the multinational corporation.
Neither of those examples is a scenario for a new movie about the world of big corporations and conspiracy theories. These stories happened in the real life. What connects them? Both are associated with the fiasco of an IT software implementation. But what actually went wrong?
Provident tried to replace their employees with the AI mechanisms, which resulted in the drop of debt collections from 90% to 57%, and total sales decrease by 9 million pounds. In August 2017, the company announced that instead of the annual profit, their books will show a loss of 80-120 million pounds. The dividend payout was also suspended. Thus, the global financial giant got into major trouble. Everything because of an unsuccessful implementation of the IT system.
Back in 2010 the management of the German global discount supermarket chain, on the other hand, made a decision to get an entirely new ERP system. The implementation process lasted for 8 years, absorbing more than 500 million euros. Finally, the management admitted to its failure. We will probably never find out what was the real cause and the actual scale of the misinvestment. What we know is that almost 1,500 people were involved in the project (including employees of Lidl, SAP, and Accenture, which from 2016 tried to save this deployment) but still till this day the company is not using the system.
If we would believe the information that circulated on LinkedIn, Lidl decided to implement SAP because they wanted to unify processes in all countries of their operations. However, the clash of assumptions made around 8 years ago with the ever-changing economy proved that the closed-source system was too limited to ever meet their actual requirements.
Let’s move on to the reasons that could lead to similar situations… Apart from a few references, we will no longer use the above examples, because knowledge of specific causes in these two cases will probably remain a corporate secret forever. Instead of multiplying speculations, let’s think about what are the reasons for such strategic failures.
1. Focus on technology instead of on business transformation.
The implementation of new IT technology should be a way to achieve or maintain a competitive advantage. You should never implement a software only for the sake of having a software. The main purpose of the deployment should be business transformation. You should be aware of your own needs and take them into consideration while deciding on the system. Often, however, reality looks different. Employees, especially management, lack basic knowledge about the goals of the business transformation. It is wrong to assume that the technology itself will be the ultimate solution to all problems in the company. Keep in mind that a business software implementation is always a hard, demanding work engagement. In this case, all shortcuts usually cost a lot of money.
2. No environment for changes
Each technological transformation has an impact on the company’s operations. It changes its revenue streams, market approach, and business model. It can also influence certain habits, know-how, the way of acquiring information or other internal processes. However, sometimes when companies decide to implement a CRM, ERP or another system, they do not really want to optimize their processes. They are not flexible or open to changes. They would like to preserve the status quo, hoping that the mere possession of the system will reflect in their financial reports. Well, maybe. More likely it will lead to another Provident-like situation.
Some press agencies stated that one of the reasons for the above-mentioned SAP implementation fiasco was a reluctance to adopt the internal processes to the system’s architecture. Choosing the closed source software, companies have to deal with the fact that some of their procedures will need to evolve just to adapt the way the system works. The situation would be different if they would go with the open source, in which it is possible to make any changes.
3. Dictate of the management
The need for change can, and often even should come from a higher management level. It is the managers who see a broader business perspective of the company’s operations. Although if a new technology is being implemented, also other employees should be involved in the process. The opinion of lower level representatives, especially “key system users” (who will perform the most operational tasks) matters and should equal the manager’s voice.
4. Global unification instead of local adaptation
A common occurrence during large, international IT system deployments is the ambition to unify procedures in all countries of operation. Managers in the headquarters express the need for standardization of processes and procedures, stressing the issue of consistent, global reporting. The everyday practice, however, very often shows that this apparent benefit adversely affects the operations on regional markets. Unified procedures are not the best fit for local specifics. As a consequence, operational employees spend their time filling in a software, as the foreign head office wants, at the same time running a separate Excel sheet, thanks to which they are able to support local sales activities.
5. The traditional implementation of long-term projects
The implementation of an IT system can last from several months to several years. The extremely time-consuming case we have described at the beginning of the article. The ineffective implementation of SAP for Lidl began in 2010. In such situations, it is worth taking into consideration the half-life of requirements for the IT system. Currently, it oscillates around 0,5 year. This means that after 6 months a half of the requirements will most likely become outdated. This type of statistics is a key argument against the traditional implementation methodologies. Assuming that the implementation project will last at least a few months, ideally, it should be implemented in an agile manner, e.g. using the Scrum framework. This would prevent the requirements from becoming obsolete. Remember that the change is something natural, it has the potential to speed up the project, it helps to adjust the current priorities, finally, it prevents wasting the budget on unnecessary functions.
