A little over 6 years ago, I was hired by the CFO of a large property management company to facilitate its software selection. The company’s situation was a little bit different—two finalists already were chosen, but the firm had not compiled their requirements. And even more troubling was the fact that they were not bringing in any other operational areas of the company for the evaluation. This was an accounting deal all the way around.

Uh-oh…Danger Will Robinson!

The company did a good job of creating the requirements. We created and prioritized the scorecard together and went through the vendor demonstrations. We did not have a tie, and the contract went to the better vendor.

Now it came time for the implementation. My firm was chosen to lead this effort. It was probably the most highly functioning implementation I have been on ever. I never ever met with one person from the operational area during the entire implementation. The entire process was driven by accounting—100 percent.

So, why did this go so well? It had all the symptoms of another difficult job. The client didn’t use an RFP and didn’t incorporate the major functional areas of the company into the process. The vendors were pre-selected based on hearsay and vibe. At least the client brought a consultant (me) in to facilitate the sessions.

It took me a while to realize why this worked so well.

And the reason was that there was almost zero internal politics at this organization. Most of the people working there had been together for at least ten years. Everybody was comfortable with each other and, most importantly, the company trusted the three people on the team to do what was right. There was so much institutional history in the company, and trust that going this route was the best call for the client. Why invest the time of six employees when you trusted these three to look after your interests?

Hidden agendas are rampant in many of these software acquisition projects. There were none with this client. And because of it, there was a quick forty-five-day software selection and a six-month implementation.

From time to time I have been asked why you need a consultant, an outsider…or much less, a methodology to evaluate and implement software solutions for organizations.

I used to give detailed explanations as to why having a methodology is so important. (You don’t need a consultant or an outsider.) Now I can just tell them to read the newspaper. This little nugget passed my desk yesterday:

“State of Colorado officials have temporarily shut down a new computer system for motor-vehicle titles and registrations after discovering a glitch. The state Department of Revenue is putting off plans to roll out the $13.2 million Colorado State Titling and Registration System, called CSTARS, because it sometimes provides incorrect information to law enforcement officials.

“When we start to hear from folks that their vehicles are being impounded, we look back at the records and say, ‘Yikes,”‘ said Maren Rubino, operations director for the revenue department’s titles and registration section.

The crash of CSTARS is the latest multimillion-dollar computer bug to dog state government, and it has prompted Gov. Bill Ritter’s administration to conduct a full-scale review of the state’s process for updating its computer systems.

Last year, the federal government notified state officials that Colorado may have to repay as much as $11 million for welfare benefits that were distributed because of errors caused by the $200 million Colorado Benefits Management System. The Colorado Department of Labor and Employment is assessing whether it can salvage an unemployment benefits program, Genesis. That project, originally costing $44.8 million, was stopped in December 2005. The agency has received $2.3 million to analyze whether the program could be saved.

Ritter spokesman Evan Dreyer said two other computing systems - a payroll program at the Department of Transportation and a voter-registration system for the secretary of state – have provided big-dollar woes to the state.

The Revenue Department will work with the state Office of Information Technology, a division of the governor’s office, to hire a consultant to review the system, said Roxy Huber, executive director of the department of revenue. The review could take two to three months.”

This is ridiculous.

If I lived in Colorado, I would be screaming bloody murder about this state of affairs. Lots of ‘millions’ being tossed around in that article. Because it’s ‘computers’…people (both bureaucrats and taxpayers) just shrug their shoulders with sort of ‘well, what are you going to do – computers, can’t live with them, can’t live without them’ mentality.

I think I may call old Roxy up and see if I can’t get some of those millions coming my way…

Good grief.

I was asked last month whether being a CPA gave me an advantage in leading software evaluation efforts…if the specialized training I received years ago was relevant to what I do now.

Answer: Yes and No.

The advantage is that people (clients and vendors) think that I/We have some sort of special something because we have reached the top of the ladder from an accounting certification perspective. But the reality is that the profession doesn’t really teach evaluation methodologies to its tribe…but what is true is that most CPAs have the temperament, organizational abilities, and discipline to be terrific software consultants.

Another misconception in what I do is that you have to be an IT technician and/or have knowledge of all of the software products.

Wrong on both counts.

I would argue that the temperament and evaluation methodology are much more important than product knowledge. After all, the goal here is to match needs (clients) to capabilities (software). Previous knowledge has some legitimacy…but the products change so fast that previous knowledge can become useless knowledge pretty quickly.

But your methodology - if you have a good one, will work forever. And as you work on more and more clients, you can make it bulletproof…to insure that the purchasing organization is maximizing its chances of making the proper technology investment.

Most of you know the story of me falling on my professional butt in 1990…when I started out in this business. Back when I was a know-it-all… My biggest of many mistakes was not embracing a rational methodology for evaluating technology.

I corrected that mistake…and have now used the same approach over and over again…with many different clients, and in a few industries besides real estate. It worked in the DOS world and it works in the web-based world.

There really is nothing new under the sun.

Old tactics work well in a new world.

Last week I mentioned scripted demonstrations…what are they and why should they be part of your evaluation arsenal?

A scripted demonstration is where you tell the software vendors exactly what it is you want to see in their software. And you lay it out for them in advance…in a script. If you do not do this, you increase the probabilities significantly that you may not select the vendor that best fits your requirements and needs.

What are the benefits to using this technique? There are a number of them, and the implications are huge:

You maintain control of the demonstration. By determining what you do and don’t want to see—and by communicating this upfront—you keep the agenda tight and focused on your needs. These scripts should flow as if people were doing their normal jobs, except that the software vendor salesperson is showing you how you will be doing it if their product is selected.

It takes some salesmanship out of the equation. By taking most of the demonstration down to “boring” functional items (which tie back to your business objectives), it takes away from some of the discussion of the newest features that may or may not be relevant to your business.

It will tell you whether the software vendor salespersons are winging it or really want your business.

Are they willing to work for your business by taking the time to create a terrific scripted demonstration?

Are they listening to you?

Will they listen to you in the future?

It has been my experience that they are not interested in doing a scripted demonstration. It is much easier to do a regular sales demonstration. You should be interested in the meat and potatoes. Hold the flaming dessert for later in the process, thank you very much.

One of the best things I did when researching and writing my book on software evaluation practices was to ‘cross the aisle’ and interview software sales professionals for their take on the whole process.

One of the questions revolved around the notion of scripted demonstrations. Here are two quotes:

“I’m a little bit different than probably some of the salespeople that you have. I mean, I’m kind of a master of my craft so I know how to weave in the zings that I want to weave into my demo. If it’s not in a script and I think they need to see it, I will make sure they see it. So I think that really depends on the skill level of the salesperson. The thing that I would rather do is go into a room and not do my demo and have the customer say this is what we want to see now.”

“I would probably say I am doing them 5-10 percent of the time. I am showing them cool functions and features that I want them to see. Well, why do I do that? Because I’m lazy…true. I don’t want to have to do a scripted demo. That is a big fat pain in the butt. I don’t want to do it. What I really want to do is get your emotion connected with my software.”

Interesting, huh?

This shows the push-pull that goes on between evaluation teams and software companies. Big time.

They want your emotions…scripted demonstrations is a “just the facts ma’am” that is ruthlessly efficient. Most vendors HATE them…they are a lot of work and they take all the excitement off the table.

More on this in the coming days.