The challenge of selecting software:
Selecting the right software for your company can be a challenge: it starts with a demo that looks good on the surface. The truth is that all demos look good the same way all cars look beautiful in the dealer showroom.
When the wrong software is chosen:
Company business requirements that were not addressed in the demo can result in costly, extensive modifications.
If the software is too sophisticated for the end users it may result in a long, expensive implementation. In extreme cases, the project is canceled and the company reverts to its old software.
Software is being chosen by decision makers based on their experiences in a previous positions without taking into consideration their users’ ability.
One of our former clients hired a new president to run the company. The president came from a larger company that used very sophisticated software. Shortly after assuming his new position, the president decided to purchase the software he used at his previous job. The department heads who viewed the software at the demo didn’t feel it was the right choice for their company, fearing the end-users who had worked on a home-grown system for 15 years might have difficulty learning it.
Despite their advice, the president decided to purchase the software. The consulting firm that sold the software guaranteed the cost would not exceed $750,000. Two years and $2.5 million later, the software was finally implemented and the company went “live.” The main reason for the cost overrun was because the software had to be modified to meet the company’s business needs, together with the very long learning curve users encountered when trying to master the system.
This resulted in the president being fired, the company having very sophisticated software with most of its functions going unused, and needed a large computer department to support the software operation.
The right way to select software:
Before the demo is given, make a list of your company’s current and future business requirements.
Give a copy of these requirements to the person who will give the demo and copies to the users who can mark off which requirements were addressed.
Make sure the person who gives the demo learns as much as possible about your company’s business requirements.
Some requirements may be missed during the demo because questions and answers are asked. This is a good way to keep track of all requirements listed.
After the demo, another requirement list should be developed based on what was learned about the new software capabilities.
Qualify the software vendor prior to making the final decision:
Make sure the Software Source Code resides on your Server. Having the software in “escrow” is not a good solution.
Not having the Software Source Code on your Server ties you to the vendor and if something goes wrong with the relationship, you can’t choose other resources.
Ask your software Vendor for three client referrals. Speak with the CEO, CFO, and IT Director. You will get three different perspectives of how the software functions.
The most important question to ask: how is the hotline support? Unresponsive hotline support will result in business disruption.
Going “live” with the new system:
After the decision is made to buy the new software, ranking priorities for the modifications need to be made.
Priority “A” modification: must be done prior to the system up and running.
Priority “B”: can wait until after the system is up and running.
Priority “C”: would be nice to have.
Often after implementing the new system, users find out that most Priority “B” requirements are not necessary since the new system addresses them.
Priority “C” is not needed most of the time because the new system addresses all business needs.
A detailed system study should be done prior to the software vendor giving you the final proposal, to find out what business requirement may have been missed.
The study will prevent surprises during the implementation and bad feelings.
Besides being a major investment, purchasing a new software system can create longer working hours for company personnel and should be planned carefully. User training is the most important piece of the puzzle. If your users are not fully trained when it’s time to go live, postpone the going live date and set a new one with which everyone is comfortable. This will result in less frustration and fewer business disruptions.