How to Avoid Inventory Management Software Deployment Failure

Retail software deployment poses unique challenges for business owners. Software deployment failure is a common issue faced by retail businesses and there are many reasons for such failures. This article draws on five real-life case studies to identify the common causes leading to deployment issues and outlines the lessons thus learned for developing strategies to overcome these challenges.

INTRODUCTION

All business software applications are purchased on the basis of expected return on investment (ROI). This means, inventory management software, like any other business investment, is considered an asset and investment in inventory software are based on its potential benefits for retail businesses for a certain period of time.

Unfortunately, unlike other business investments, the rate of software deployment failure is quite high and quite often software fails to deliver the expected benefits. Since new software deployment requires changes in the existing processes, failure during deployment may seriously affect the organization’s operations.

Quoted below are some of the instances where inventory software deployment suffered partial or complete failures and delays. For privacy reasons, the names of the organizations are not mentioned, but all these real-life stories provide us with enough insight into the most common reasons for software failures. Understanding these factors can help us avoid these problems at our organization.
It is important to note that the examples quoted below are not related to new software development projects which are far riskier and failure prone. Rather these examples refer to pre-packaged software applications that were available for deployment albeit with some required customizations. The customer was able to make an assessment of the features and capability of the available software solutions before making a business commitment.

Change is Hard

Case Study 1

It was almost 3 months since the software installation and deployment started. But it was still far from complete and people had already started speculating that the software effort was heading towards failure and abandonment. The general manager operations, who took the initiative of software purchase and deployment, conducted a meeting with his staff and the software consultants to find the reasons for the impasse. A strange reason surfaced.

It was found out that the data entry operator (who was operating the new software) was facing considerable delays in getting the production sheets which contained the required data. Since he didn’t get those sheets in time, he couldn’t enter the data and the whole process couldn’t proceed further, hence, the deadlock. The matter was resolved only when the chief executive issued strict orders in this regard.

Lesson Learned: Generally people are risk averse and do not like change. Change management is critical for the success of software projects. Regular feedback meetings should be held to gauge the progress of the deployment and corrective actions should be taken before it becomes too late.

Case study-2

At another medium-sized organization, deployment of a new software system was delayed because of resistance by the operational staff. The staff was familiar with the existing software solution and did not want to learn the new software. Different excuses and reasons were invented by the staff to resist the new system. Eventually, the top management became fully involved in the whole process of deployment, and the managing director started having regular feedback meetings. Once it was made clear to the staff that the organization had made a significant financial and time investment and the new system would be deployed at any cost, they had to switch over to the new system. Although the project was delayed a major disaster was avoided.

Lesson Learned: Decisions regarding new software business solutions are taken by the top management based on their strategy and vision. The people at the operational level, who are going to implement these solutions, may not have this understanding. One important way to make them realize the value and importance of these solutions is the level of interest the top management shows and demonstrates. Lack of top management involvement is one of the major reasons for failure in software project deployments.

The simmering pot of office politics

Case Study 3

In a similar instance at another company, the whole process of software deployment came to a standstill. There was almost a boycott of the new software being deployed at this medium sized organization. The in-charge of a very important department started saying the new software was not practical enough and the organization should continue with the previously deployed software instead of wasting time on the new one. Many other people sided with this department in-charge and general resistance to the new software developed in the office.

Change management is critical to the success of software projects. Regular feedback meetings should be held to gauge the progress of the deployment and corrective actions should be taken before it becomes too late.

At this stage, the chief executive intervened and called a meeting of all department heads. He figured out that the whole problem stemmed from the inability of the unsatisfied department in-charge to use the new software. It was decided that instead of the department-in-charge a junior data entry operator would operate the software while the department head would do his routine work using conventional pen and paper.

After the meeting, the unsatisfied department head came to the general manager and apologized for his behavior. He confessed that the IT department head, who had developed the previously deployed software, asked him to resist the deployment of the new software so the company could continue with the old system. He admitted that he was misguided.

Lesson Learned: Software deployment can suffer failure due to internal politics and internal pressure groups. Top management should be aware of such possibilities and remain actively involved in software deployment to avoid such scenarios. Top management involvement and regular feedback can greatly increase the chances of software success and achievement of the desired objectives.

Error of Judgment

Case Study 4

A textile company, after the hectic effort of one year, had to eventually abandon deployment of a new software system. During the course of the deployment, they not only lost around half a million rupees as a service fee to the software provider but also had to bear the cost of effort done by the staff. Moreover, the company was still on manual systems which were much less efficient than the expected automated system.

The textile company had selected this software provider from amongst five different vendors who were considered for the software solution.
Before selecting this vendor different people were consulted, including a friend of the director who was a software professional. But the Final decision was taken on the basis of the director’s judgment about the personality, presentation, and honesty of the owner of the software company. The person representing the software company was indeed an honest person but his organization did not have the capability to deploy the system. The software provider lacked resources which delayed the project and ultimately the project had to be canceled.

Lesson Learned: Software deployment is expected to suffer failure if the consultant company has insufficient resources and lacks the technical capability. Besides evaluating software and its available features, the consulting company and its staff should also be evaluated. Great software products can suffer failures due to weak consulting companies.

Every engine needs a driver

Case Study 5

This case pertains to a manufacturing company where after many months of futile software deployment effort, the chief executive had to stop the software project and revert back to the manual system. During the course of software deployment effort, the manual systems were also lost and the organization was in deep trouble. The financial year was coming to a close and people in the accounts department were struggling to collect the required information.

A detailed meeting was held with the representatives of the software provider company. There as one surprising fact: the same system was successfully deployed by the software provider company at another manufacturing organization which was located just fifty meters away.

It was found out that during the course of deployment effort, which lasted for around six months, the project ownership was shifted to different people in the manufacturing organization.
None of them was able to perform the assigned tasks. Many people, including the data entry operators, left the organization during the project. The organization did not have the right people who could take responsibility for the project.

Lesson Learned: No matter how efficient and automated a software solution is, it cannot run by itself.
Before going for automation and software projects deployments we need to make sure there is a trained and capable staff to take on the challenge of running the new software. During the course of software solutions deployment, when an organization is going through a major change in business operations, we need to train and retain people who can take the ownership of new systems and drive this initiative.

Conclusion:

By looking at the above examples of total or partial failures in software deployment efforts we can safely say that most of these failures can be avoided by taking corrective measures at the right moment. Taking corrective actions become easier if we are aware of the potential risks and prepare for them in advance.