Last week I spent quite a bit of time explaining budgeting to a client as it relates to software evaluation and implementation…wasn’t the first time I had been through this with them.

The problem was when I spoke with them in February, I used a plural and they only heard a singular.

Here’s what I said: You need to make sure and prepare your software budget(s) before you start the evaluation process.

They heard ‘budget’ – singular…and because of this, things have gotten a little gummed up.

There are actually two budgets that need to be created.

The first budget is the software evaluation and acquisition project budget. This is how much you are going to invest in fact finding and evaluation.

The second budget is the actual software acquisition and implementation budget - this includes all costs (hardware, software, consultants, present value of license fees, etc.). This second budget often is wrapped into a formal return on investment calculation. The expected return can drive the investment amount, which in turn drives the maximum amount the company is willing to invest in software.

It is within the realm of possibility that after you get preliminary numbers from software vendors (this is the vendor long list process discussed in my book), that the acquisition costs are sufficiently high to NOT warrant acquiring new software. The numbers don’t make sense – in other words, the expected returns are not high enough relative to the cost of acquisition.

My client prepared the project budget…but never went through the process of trying to quantify the benefits that would accrue with a new system.

They are still going through with their software effort…but from a corporate standpoint, they don’t know why they are, and what they expect to gain.

Was an uncomfortable conversation, but one that was necessary and educational.

Does human intuition have any place in evaluating software?

Uh, that would be ‘yes’.

What did your intuition tell you about the people who were demonstrating the product?

You just spent quite a few hours and possibly days (weeks?) with the vendor’s representatives, which may include senior executives, and maybe the firm’s founder and president.

Were they straightforward? Did you feel like they were honestly listening to you? Did they ever say something was their fault? You developed some sort of vibe about the company, and one of the things you need to take into consideration is whether you had a group vibe about the sort of company the software vendor is. How do you evaluate this vibe? You don’t. But you discuss it as a group and make sure it is one of your X-factors at the end of the evaluation effort. In 1990, I led my first evaluation effort.  One of the software vendor’s demonstrations was horrible.  So horrible that the two sales reps actually got into a fight over who was going to continue to lead the disaster…culminating in them each putting their hands on the keyboard and doing the push-pull thing.  Each trying to wrestle control of the keyboard (this was before the ‘mouse’). Our collective vibe told us that we needed to give them a second shot – with different sales professionals.  The scoring for this vendor was a zero. 

Long story, short.  The vendor did come back – brought the president of the software company with them, and did in fact win the account.  A large part of this was due to the damage control that they did…but in a small part due to the project team using their eyes and ears to do the right thing, and not JUST depending on the evaluation methodology.

My firm was engaged several years ago to do a soup to nuts evaluation of a governmental entity. Included in the engagement was a definition of needs, a documentation of existing processes, the creation of an RFP, and facilitation of the vendor evaluation effort. Overall, it was a good effort—we came in on time and on budget.

The problems arose during the vendor selection effort: we had two firms that were a virtual tie in terms of functionality and price.

Early in the process, I had mentioned the notion of creating x factors (tie breakers) for just this purpose. The team didn’t want to do it because they said the factors were not measurable.

So, there we were, stuck in a conference room with no direction and every person in the room looking at me. The executive director of this organization walked in the room at that time and he also wanted to know what was going to happen. At this point, I mentioned the team’s reluctance to create tie-breaker mechanism in advance. Everybody nodded and continued to stare at me. Crickets chirped.

This was new terrain for me, and then I had a terrific idea.

I tossed this little nugget out on the table: “How would everybody feel if we took a straw poll and everybody wrote on a scrap of paper who they think should be our vendor of choice?“ The executive director looked and me and said he was thinking the same thing. Well, there we had it…a new methodology.

Everybody wrote down their decisions and handed them to me—and I read out the answers. One vendor had seven votes and the other had two votes. A little more discussion was had, but the vendor with seven votes won the contract.

My lesson learned was encapsulated in the deafening silence and stares. My mistake was not making them come up with tie-breaker criteria. Never again. I have kept the scrap pieces of paper in my office as a memento and a reminder that there is always something to learn.

I read this sentence this weekend…gave me reason for pause:

“A store is nothing more than an aggregate of customers and the trick is to pay close attention to what they want rather than what you think they should buy.”

It’s relevant in my business, in my software evaluation projects, and to your business as well.

All of us get stuck in this mind sometimes of trying to shove our wares down the collective throats of our prospects and customers…rather than stepping back and taking a macro view of what those same groups want and desire.

I’ll admit that I have been guilty of it.

Usually takes somebody in one of the business groups I belong to hitting me with a 2×4 to get me to get it.

It happens ALL THE TIME when I’m at a client site and software vendors are doing a product demonstration. Without fail, they will be bound and determined to show the latest dazzling feature even though it has nothing to do with my client’s needs. Doesn’t even matter if I interrupt and say, “Thanks…not interested”.

They have cool functionality…and by God, the client is going to see it.

It’s called selling features (seller’s product), not benefits (buyer’s desires)…

So, the question for today is this…are you selling features instead of benefits? The question is relevant where you are in accounting, IT, sales, own your business…or you don’t.

Read between the lines and think about it.