How many fixes to a software solution before you decide to replace it ?

The system had gone live after a bit of delay; everyone sighed in relief and believed that the best is yet to come with the long awaited solution that should deliver a competitive edge before others caught up. The system automated processes that were thus far manual and in a geographically spread business where collation of data took some effort; standardization using spreadsheets had not delivered the desired result. Thus anticipated benefits from the system were high as the deployment completed as per timetable.

Giving some credit to the implementation team comprising of business, IT and the vendor, they had attempted supporting the business to institutionalize the effort. Time passed by, the usage graph gradually started declining reaching a level that rang alarm bells. Response time was the first issue raised followed by bugs, functionality limitations, lack of reports and analytics, it appeared that everything that could go gone wrong had. The challenge was thrown to the new IT leadership team to diagnose and fix.

A crack team was created to deep dive, assess and document the root cause and find a solution to the predicament that faced the enterprise. The team spent more than a month meeting members from IT, business, vendors, software principal, and key users collating information that would finally create the prescription to remedy the situation. The laundry list thus created needed budgetary support and resources to get started; so the CIO sought audience from the business head and the CFO.

With aplomb the CIO personified in most meetings, he presented the findings to the assembled group. It was more than a year since the solution had been deployed; barring basic functionality, users had stopped using it, reverting to time-tested quasi manual process. The investment had failed to deliver commensurate benefit. Fair evaluation of the solution had reported 85% fitment to requirements. The implementation partner recommended by the principal had struggled but finally delivered the desired solution.

As the discussion progressed there was growing discomfort in the room as the list of changes appeared unending. It challenged conventional wisdom to implement any solution with minimal changes or customizations. The CIO pushed a long list of 117 changes to the COTS solution over and above those done as a part of the original implementation promising everything the business wanted. The ask was budget almost equal to the total project cost thus far and timeline spread over more than a year.

For the business head and the CFO the decision was between scrapping the project and putting time, effort and money to rescue the project which promised significant operational and process improvements. The conviction of the CIO swung it in favor of putting some more money behind the challenged project. The business team was asked to prioritize the long list by putting it into different buckets based on impact and effort. The budget was scrutinized by the Finance team and the list of 117 changes was approved.

Quick wins came easily, re-use of the solution jumpstarted with delivery of the high priority items on the list. Emboldened the team pushed ahead only to face roadblocks on technology as well as stability of the changes. Three quarters later the list was pruned and the internal and outsourced development team given the stick; the business disengaged from active participation deciding to get involved whenever a delivery happens. The project was relegated into the background keeping the team busy, often pulled out for other pressing activities.

The now floundering project became the white elephant in the room in review meetings with IT. The CIO exited under mysterious circumstances replaced by young blood; triggered by a strategic review conducted by a veteran consultant, rational thought and direction on the project finally saw light of day with the approval of an alternative solution to replace the infamous mess. News of scrapping of project created flurry of activity; the Principal vendor sought to intervene, a request that was promptly denied.

Where did the project go wrong ? Initial evaluation was extensive and could not be faulted; the now approved new solution came across as the winner; the incumbent solution was the next best choice by a small margin functionally but at half the cost making it an attractive option to consider. Are next best choices not good enough ? Was the implementation flawed or people competency a challenge ? Was the CIO correct to push for large number of changes ? Why did he not propose the other solution ?

At times people are blind to right choices; they push low cost or safe choices, or put good money behind bad as was this case with irrational prevailing; the CIO avoided conflict by not confronting past decisions and thus lost the opportunity to create better outcomes. Compulsions if any remain a mystery between the business head and CIO. Opportunity lost, time, effort and money wasted, the enterprise is the final loser. I don’t believe that many would approve such elaborate customization, but I may be wrong !