As businesses evolve, systems must as well to sustain growth and stay ahead of the competition. Do you now need an ERP, or does the existing system no longer work for you? Do sales need a more sophisticated CRM tool to track sales cycles and win rates more accurately? Have desktop issues within the organization become overwhelming for IT? Does cross-functional collaboration suffer because the technology is outdated? This is a small sample of the problems we solve for our clients.
You have invested a ton of time, sweat and money into your business, so don’t make the mistake of letting a vendor sales rep tell you what you need. Take the time to figure out your needs first, then make vendors compete for the right to call you a client.
Below are some vendor selection best practices that we recommend to our clients to better the chances of realizing your investment in any new technology.
- Understand who all the stakeholders are, not just the ones that will directly use the software. How does everyone consume the data, how do they receive it today, what do they do with it?
-
- Who will be implementing the solution, including interfaced technology?
- Who are the business administrators once implemented?
- Who are the end users?
- Who needs to help make the decision? Legal, InfoSec, Finance, etc.
- Vet business requirements using process flows (I like swim lanes to understand the actors). Understand the cross-dependencies (where data is passed between business units (see point 1). When constructing the Business Requirements Document, or BRD, use visuals from the flows to detail each requirement. Most people are visual learners, and this will help vendors better interpret your requirements. In addition to business requirements, be sure to include an existing system architecture for the impacted areas. If one does not exist, get with IT to create one before sending to potential vendors. Be thorough!
-
- When developing requirements, consider that these could be used as future system testing and user acceptance scenarios.
- Divide requirements into Technical Requirements and Business Requirements
-
-
- Technical requirements – if the solution is on prem, what sort of storage, server, network, SSO requirements are there? If the solution is SaaS, ensure all security reviews are complete. What sort of technical infrastructure needs to be in place (e.g., versions and functionality of interfaced technology)
- Business requirements – how does the user interact with the solution (User Interface), workflows, etc.
-
- Do not skimp on detailed requirements in the interest of time. Give yourself 2-3 months to properly gather, if possible. Eventually this will catch up to you and cost real dollars! Use the 80/20 rule as best you can.
- Have a strict schedule for vendors to reply including dates/time for basic questions (can be email or live, I prefer email to keep it from getting personal), short-list awards, oral presentations, award of winner and contract negotiations. Do NOT communicate outside of the schedule, as salespeople will look for any competitive advantage they can get, and that does not benefit you when it comes to negotiating power.
-
- Allow for all vendors to participate in an open Q&A about the RFP to address questions and drive fairness between vendor responses.
- For oral presentations, demand a demo of the product as part of the presentation. Choose one stakeholder from each business unit to score the presentations and ask tough questions that impact their areas. Don’t try to represent someone else in your organization; make them be accountable. Use an objective scoring tool to judge each requirement (I like a 1-5 scoring system to keep it simple). Also, make sure IT has a seat at the table. Don’t be fooled by the demo. It was created to wow you, and rarely does it come out of the wrapper looking like that. Be clear on what is custom-built and what is configurable and make them show you how to configure to meet your requirements! Custom code = more dollars=scope creep=unhappy client! You may also want to consider creating scripted scenarios that the demo needs to follow. Each vendor would demo the same workflows and demonstrate the same functionality.
- Ask for best practices for implementation; phased versus big bang and why they recommend this. What are the cost differences? What have other clients done and how did it go? Users need to adopt it to realize your investment, so make sure that is a major consideration before deciding how best to roll it out.
- Don’t trust vendor references. If possible, do your own research on who else uses the solution, and ask them about both product functionality and the implementation experience. This could be a tall ask to find these people, but rest assured you are not going to voluntarily get bad references. You may do this as part of the requirements gathering effort, prior to sending out invitations to compete. Request that the vendors provide customer references and conduct reference calls with other customers to understand their experience with the implementation, using the product, and partnering with the vendor.
- When the vendors submit a price quote, consider conducting a financial NPV analysis factoring in direct (implementation and professional services fees, platform and license costs, other-system interface costs), and indirect costs (new FTEs needed to help maintain system).
- After selecting a winner, clearly identify any custom code requirements (extension of point 5). Clearly articulate that if custom code is needed in areas that were previously discussed that cost and labor burden will fall on the vendor. Entire projects can get derailed by this, so cover yourself up front from such surprises.
There is a lot to lose by hastily choosing a solution to whatever need you might have. Take the time, spend the money up front, and make the most informed decision for your organization. To learn more, contact us directly.
