No matter the type of system, merchants tend to make the same mistakes when shopping for software. These errors can lead to budget overruns on the initial implementation, a higher than planned total cost of ownership, and a general failure to deliver the expected business value and return on investment
You can avoid these headaches if you steer clear of the following systems selection mistakes.
- Having the wrong expectations
There are typically five things management always wants to know upfront in the project before the system selection process proceeds:
- type/tier of software that best suits the company’s needs
- a preliminary gap analysis of your business compared to the commercial systems available
- preliminary total cost of ownership for the entire project
- a schedule to complete the process
- resources — both internal and external — required to implement and support the project
Management will want the answers before granting approval to do the detail work. Just be sure your answers don’t create unreasonable expectations for the project.
- Counting on IT to do everything
It’s not just IT’s project: Large-scale systems will change the way your company does business. So assemble a strong project team of all the departments that will use the system.
Be sure to have executive sponsorship that supports the project from start to finish. You will need a project manager capable of coordinating and supporting project.
Don’t rely on the vendor’s project manager to manage the process. For large system projects, this is a full-time job; if you don’t have the resources, seek outside expertise.
- Failure to develop detailed business requirements
You must develop a requirements document, gain user sign-offs, and turn that into a request for proposal document or design document.
An order management system, for example, may have 2,000 unique requirements. Interview each of the functional areas that are stakeholders in the new system. Don’t re-create existing systems in the requirements. Address the functionality, not necessarily how it should be accomplished.
Document software interfaces to other necessary systems, including the data points and the frequency with which data is passed. Have a select group review requirements to make sure they’re in line with the company’s strategic direction.
Tell vendors enough about your company so that they understand your business. Include background — corporate goals and objectives for the project; time frames to complete each step of the project, including deadlines for vendor responses to RFPs; transactional volumes and user counts; directions on how to respond to RFPs, etc.
- Limited search, limited vendors
Too often, companies do a few quick demos and then think they have the best vendor choices. Keep your options open — don’t settle on one vendor prematurely.
Initially, you want to consider all the vendors that sell or license applications you are looking for and then, in an analytical manner, develop a short list of three or four vendors to review range of functionality and services, and negotiate price.
No one vendor is a perfect fit for all companies. Aim to get at least an 80% match of the critical functions.
- No competitive bid process
Conduct a multivendor bidding process. Not only will you get the best price, but creative vendor analysis and proposals may give systems insight into your business that you would not have otherwise gained.
Vendors are underused resources — their questions may make you think differently about your operation. Keep two finalists until the very end. Too often companies develop a favorite vendor; your staff or a vendor probing may actually short-circuit the competitive bid process.
- Picking technology over functionality
Balance technical decisions with all factors. Yes, platform and systems technology is important. But how much functionality are you giving up by selecting the most leading-edge technology?
Deciding on technology foremost without sufficient functionality can be an expensive mistake: You have to strike the right balance. Make sure you’ll be able to integrate with other business applications.
- Too many modifications vs. adapting to a new application
Companies often try to make the new system look like their current system. You should minimize modifications throughout the process, at least initially. Modifications add risk and cost, and extend time frames or make the system undeliverable. Merchants abort implementations every year because they underestimated the effects of the contractual modifications.
In software demos and discussions, evaluate the vendor’s alternative processes rather than deciding to modify. Challenge modifications deemed “necessary” after reviewing the alternative processes. Consider changing your business processes or using the system “as is” for six months before making certain modifications.
- Superficial demos
Merchants frequently select complex order management or warehouse management systems based on spending a few hours on a vendor demo. This makes no sense: These are complex systems with hundreds of functions — you need to schedule one to two days to see everything.
Scripted demos need to include key functionality related to your business. From the RFP responses, what do you need demoed?
Prepare in-depth examples with your data, and send them to the vendor in advance. Be sure major stakeholders are involved throughout the demos and that each functional area participates. Develop a process to take notes and record follow-up points.
- Insufficient vendor due diligence
To make the best decision, visit client sites with similar merchandise and operations using the version of the software you’re purchasing. You wouldn’t believe how many companies never see the product “live” in a similar company before signing.
Perform scripted client reference checks, asking the same questions of as many vendor clients as you can. Asking the same questions will let multiple people in your company participate and compare answers.
Request the full client list, not just the staid top references. Talk with new clients that have just gone live as well as those that have been though a major version upgrade.
- Signing the contract prematurely
Avoid the sales person’s push to close the deal with offers such as “I’ll give you 20% off if you sign by month’s end.” Don’t rush the process, and don’t let a vendor sidetrack your process by using sales tactics designed to end your competitive bid process.
Proceeding to review a contract should be based on the buy-in from the project team and sponsors. Avoid signing a letter of intent or license agreement without having all major modifications, services and implementation plan detailed out — deposits are nonrefundable.
- Not having fair and balanced contracts
You need a good contract in the event that disputes, arbitration or court hearings arise. Most contracts are obviously biased toward the vendor.
There are two major aspects to contracts that deserve your attention. First, the business case, including detailed modifications, conversion, services, hardware and software, pay for progress, implementation plans. Many of these points are never addressed in contracts unless you demand the vendor amend the boilerplate agreement to do so.
Then there are the legal terms: Have an intellectual property attorney review language and terms, and add the agreed-to language for business case. Merchants typically fail to do enough work here.
Buyers often use attorneys who don’t have this expertise. We work as an expert witness in lawsuits regarding systems, and it’s appalling what gets left out of the contracting process.
Incorporate all key materials and promises made into the contract. Nothing agreed to verbally is enforceable if it is not in the agreements. It’s left up to interpretation by a judge, jury or arbitrator to decide the importance if you can’t reconcile it with the vendor.
- Underestimating the implementation time frames
Demand that detailed project planning is completed and part of the contract. But don’t force implementation if it’s not realistic to compress dates.
Build in contingency time for when certain aspects of the plan run longer that expected. Most companies do not plan enough time for file conversions, integration planning, modifications, programming and testing.
Make weekly project meetings part of your discipline. Within 30 days of the “go live,” move to daily calls and meetings.
Buying a system is a huge investment, and a lot can go wrong during the process. But if you’re disciplined and aware of these pitfalls and able to avoid them, you chances of success will be much better.
Curt Barry ([email protected]) is president of F. Curtis Barry & Co., a multichannel operations and fulfillment consulting firm.