People buy with their eyes

Software is a visual thing. You are able to see what it looks like, if it can do what you want it to do, and how it does it.

Imagine this. I am looking for a piece of software that takes the items in my fridge and turns them into recipe suggestions for dinner.

Smartchef is a new (fictitious) app that says it does this for me.

I want to know how easy it is to use, how well it can handle different combinations of things and whether the kind of suggestions it throws out are edible. I don't want 7 days of omelettes.

I could make the decision one of two ways:

a) by looking at video of the software in action, or even better, trying it out with my 1 egg, a yoghurt and a cheese string combo

Or

b) just reading a written spec that says it can turn the aforementioned fridge contents into an 8 course tasting menu

Given the choice, im going a), aren't you?

Can you describe it for me?

Procurement processes are designed to promote fairness, a level playing field and structured evaluation.

Enterprise B2B software purchases go through the same rules as everything else, they need the governance of a formal process. They need the same evaluation criteria and scoring method for all participants.

Cerrtain things lend themselves logically to a written response as they are based on a consistent standard.

It makes sense then that a pre-requisite of qualifying to participate ought to be proving the right levels of tecnical and financial robustness. The right certification, policy and business processes.

What is illogical is conducting detailed evualtion of a technical spec, the requirements for the solution, with a paper based exercise that has the supplier DESCRIBE how their visual software does the things you need it to do.

That tangible thing that you'll be looking at and using when you buy, is reduced to a paper review.

Same checklists, different method

You want to know if my software does what you need it to do. You've got those requirements captured. You have deep experience of what you do and how a piece of software would help (or hinder) making that happen.

You want to know:

• Does it meet these requirements?
• How effectively does it fill each one (how helpful will it be)?
• How does it do these things (how easy it will it be)?

What's the best way to check that?

As suppliers we want to show you what we've got. Nothing articulates our product better than our product. And if we don't want to show you, you should be worried.

Your questions and checklists and scoring can all be the same to keep the integrity of the competition.

Just don't get us to write down how it does it, get us to show you. Forensically examine the things you're going to be using.

• Give yourself enough time for the complexity of the solution. If it needs 2 x 2 hour sessions, do them
• Step through your use cases to answer your requirements. Nothing will tell you more about what you're buying than seeing it manage the thing you're buying it for
• Make sure all the users are represented. The people who just need reports, or data exports, or read access are still relying on the system
• Ask all the questions. Even the little ones. The most simple functional gaps can often be pretty meaningful day to day when you're a user

Written responses leave too much room for interpretation, ambiguity, incompletenes. They're too one-way.

Overinvest in spending time looking at the thing your're going to spend all your time looking it.