How Do You Really Evaluate a Software Vendor?

When making a decision about what software to purchase for a particular task, you consider many of the obvious characteristics, including: (1) Functionality, (2) Integration, (3) Reliability, (4) Ease of use, and (5) Price. One area that is often overlooked might actually be the most important of all: The adaptability of the software, over time, to your ever-changing needs.

Your Decision Should Be Based On The Ongoing Solution, Not The Necessarily the Solution On Day One.

As the old software industry adage goes, “you never finish a software package; you just ship it.” These days, we don’t “ship” software anymore, but the adage still applies. What you see today when looking at a demo is simply that, a snapshot of today’s solution. To make a decision about a successful implementation, you also need to imagine what it will be like in six months, twelve months, two years, three years, and further. It matters what the software does today, but it matters even more what it is going to do tomorrow. The solution got to the “today” point without your input, but where it goes from here could potentially include your feedback.

What Types of Software Companies Are There?

We have experienced them all.

There is the software that is what it is and it’s unlikely to change or adapt – this is most common when one company buys the assets of another company and the original developers are no longer involved in the product. In this scenario, almost by definition, significant forward progress on the software is virtually impossible.

There is the “over-promise under-deliver” company. This is more common with newer solutions. There may be some glaring holes in the functionality (or reliability), but the customer is promised that those gaps will be closed soon. Just so you all know, “planned for six months from now” is computer industry parlance for “we haven’t started it yet.”

Then there’s the flashy new user-interface put onto an immature engine. This is fairly common for newer companies that wow you with the “cool new idea” and pretty graphics, and a “knock your socks off” demo. But then deliver software that is not “fully cooked” – meaning that the technology has not matured enough to provide sufficient flexibility or reliability for many of your needs.

What Kind of Software Company is the Best to Find?

Finally, there is the company we all seek:

(1) They have been around long enough that the product has matured to become stable and useful, covering most scenarios.

(2) It is not an “acquisition” sold by a venture capitalist to a large company; the original designers are still maintaining and growing the product, keeping it on a strong trajectory to resolving your ever-changing requirements as they emerge.

(3) The company really listens to your suggestions and requests and implements them over time.

The first two items can be found by seeking a vendor who has been around long enough to have a mature solution, but not so long that they sold off and lost their designers. The third item is the hardest and yet most powerful to find.

How Can I Even Identify if That Third Item is There Before Making a Purchase?

Here is a trick that is rarely used for these decisions, but when applied it works beautifully. It comes down to what questions you ask when you are investigating the solution for a purchase.

1. The first step is to schedule a product demo, and ideally ask that one of the engineers be available for questions during or after the demo.
2. As you view the demo, think about adjustments and enhancements you would like to make to the solution.
3. Then ask, specifically, if the company can accomplish your special objectives that you considered in Step #2.
4. Here is the most important part – listen to the answers, and make sure you have somebody in the meeting who can determine if the answers are genuine or made up. I mentioned in Step #1 that the company should have a development engineer available to help with the answers. If you are not a developer yourself so you cannot ascertain the veracity of the answer, you should make sure you have a programmer-type in the meeting. Your technical person’s job is to differentiate a real answer from a fake one; the vendor’s developer should even be willing to show you where, in their source code, they would make those changes.
5. I’ll reiterate the end of Step #4: The developer should be willing to show you where, in the source code, they would make those changes.

Showing Me, The Prospective Customer, The Source Code?

This sounds crazy doesn’t it? Have you ever asked to see the source code when asking for a vendor demo? I bet you haven’t. Think about what it says when they cannot do that, however. If they cannot show you what they would change when you are being introduced to the solution, how are they going to find the time to make those changes after you buy it? If there are walls and barriers that they bring up when making this request, won’t they be the same walls and barriers later when you really need the changes?

Try It – You’ll Like It!

The bottom line is that if you want to buy a solution for what it does now, and you do not care about what else it can do for you in a year or a few years down the road, then maybe it doesn’t matter if they have no way to demonstrate any ability to change and update the system.

But if you want a system that grows with you, that is on a trajectory to improving to fit your ongoing needs more and more as time progresses, this approach is inimitable.

We welcome you to try it with BrightArrow. You have many choices for mass notification, but I challenge you to find out how many of those choices will be an open book for sharing with you how they will adjust to your needs.