May 12, 2010, 12:42 PM — Everyone was excited about the roll out. Expectations were high - all the users were trained, the consultants were happy, and after months of work and a pile of money, the budgeting system is finally ready to be rolled out. The executive who was pushing and pushing for completion finally smiled. Final cost: $3 million.
Flash forward a year or two. Only one or two people are logged into the application at any time, no one reads the reports that are printed out, and the executive that sponsored the project has taken his Golden Parachute. The users who were so well trained have reverted back to spreadsheets and email, and business seems to be moving along fine. Meanwhile the $3 million is in its second year of a seven year capital amortization schedule.
[ Project management: Scrapping a doomed project ]
Lots of money and time were spent putting this beautiful system in place. Reams of paper and gigabytes of space were devoted to all the process diagrams, charts, user interviews, and requirement documents. A whole cluster of servers were bought and are being managed to run this behemoth. The annual maintenance bill just came in, and it is a doozy. And yet, all of this is sitting on the sideline, unused.
This is a failed system. Whatever the original intent of all concerned, the application is not being used to address the issues it was designed to address.
There are many reasons an application can become a failed system. Lack of proper process work, lack of user buy-in or training, lack of executive support, faulty configurations, etc., etc. Untangling a failed project is difficult. Sometimes, despite all the work to put them back on track, failed projects just stay failed.
What do you do? There are a lot of things you can do to try to salvage a failed system. One solution that has to be in the arsenal is punt.
Yes, this is drastic. It is an admission of failure. It is politically difficult. However, if the system is dead, saying it is still alive (and continuing to pay for it) is worse. The system needs to be fixed, or turned off.
It is always better to get a system working than to turn it off, if you can, but before spending the time and money to try to salvage a failed system, there is one question that must be asked:
Is the system really needed? Does it solve a legitimate business problem? If it does, then by all means, do what you can to salvage the system.
But, one of the reasons users abandon an application is that it just does not meet their needs at all. A cold assessment of the situation could reveal that the application was ill-conceived in the first place. If so, kill it. Or at least schedule it for execution. If it doesn't meet the needs of the business, you don't need it.
See also:
In-memory Databases Do Not Excuse Fat, Bloated Applications
The Three Rules of Reports
Third Party Software Support: Yes or No?
Mark Patterson blogs about ERP, CRM, Financials and other business software for ITworld. Follow him on twitter @dudester.
