Preparing for the initial software vendor meeting is a crucial step in the vendor selection process. This vendor meeting will determine whether you'd like to continue considering this vendor or not wasting more time on them. The process is similar to interviewing job candidates and only moving forward with the candidates that management feels can fill the role.
It is assumed that research has been done on the software vendor that will be met with. A good first sign is that the vendor has a robust website with case studies as to how they helped other clients. Also, the products they offer should be prominent and the associated information easy to navigate.
In this article, we'll discuss how to prepare for a software vendor call.
What is a Software Vendor?
A software vendor is an external organization that will handle all the development efforts for the final product to be produced for the project. Many times, the vendor already has a base product that they can modify to the specific needs of clients. Other times, they will have a development team that can help the clients build a product from the ground up.
When to use a Software Vendor?
Software vendors are generally used if the internal development team (developers who are employees of your organization) is not able to construct the product desired. There may not be the necessary internal development team resources available to build the product or maybe the team doesn't have the expertise in a particular technology. Another factor is that the vendor's product is favorable to use rather than building a product from scratch.
What questions should be gathered for the vendor call?
Understand Your Specific Use Case. What problem are you trying to solve? What are some of the high-level requirements you need solutions to? For example, what types of management reporting will the vendor need to provide to the PMO? Will your company manage the IT Finance process through the vendor tool? Before the vendor can help you, you need to help the vendor understand your major use cases.
What can the vendor do for your specific use case? Now that we've explained the use case to the vendor, how can the vendor solve your problem? Can they make the modifications to their base product to meet your needs? Normally, there may be a brief demonstration on the first call for you to see the base product. Alternatively, a specific meeting can be arranged for a detailed demo of the vendor's product
What is the structure of the vendor team? Understand who will be working with you so you know that the vendor team will be self-managed. If the vendor team is too small, you may wind up managing them to ensure they get work done on time. It's better to have counterparts with the vendor such as a vendor project manager or vendor business analyst. This way, there's someone else to manage the detailed vendor work rather than you.
Where is the vendor team located? If you work in the United States make sure that the vendor has their implementation teams in the same region. Or, at the least, make sure the implementation lead that will be accountable for the vendor's work is in the same region. If you are located in the United States and the entire implementation team is in India you will be facing either very early morning meetings or late night meetings. You need to keep this in mind to avoid project teammates burning out.
What type of support is offered once the product is live? Where will the support team be located? What is the process to schedule sprint releases based on items in the backlog that the business wants implemented? Have them provide an example of a support process that they've set up with another client.
Who should attend the initial software vendor call?
You normally won't need the entire technical implementation team on the initial vendor call. Since the conversation will be focused on higher level requirements such as the above, it would be great to have the decision maker for the vendor selection as well as a subject matter expert (SME) who can clearly explain the problem statement to the vendor. Later, when you have meetings to discuss the technical aspects of the implementation, you can bring technical resources into the discussion.