Immediately following The Wizard of Oz, Judy Garland went into production on the Mickey Rooney movie Babes in Arms. In this movie, Rooney plays Mickey Moran, a talented singer and musician, son of a veteran from show business. Garland plays a pretty girl who is also a very talented singer. One day, a big opportunity arrives for Mickey, a big contract to set up his own show. However, things don’t go well, and to avoid being sent to a work farm, he decides to improvise a show in the country, despite the awful weather conditions. And then comes one of my all-time favorite exchanges:

“Hey kids, let’s put on a show!” Mickey says.

“We can use my Dad’s barn!” Judy says.

This same “gee-whiz, let’s just rush ahead with this project” attitude is something I have seen on numerous occasions with my clients.

A not untypical scenario would entail the IT manager being summoned by the president of the organization and told to find a new software package for the company. And that’s what he does; he goes out and finds a package on his own. He puts on a show and uses his dad’s barn. It’s a hasty, quick, impromptu activity that does nothing to move the organization forward. It’s probably not the right vendor or the right functionality—but it is a package. And it is one that most people in his firm have heard of. Low risk for him, and it didn’t take much time or effort to sign the contract with the software vendor.

The problems occur once you start planning the implementation and conversion from your existing systems. Functional items that the IT manager assumed would be in the new package aren’t there because he didn’t ask and he didn’t plan.

Remember the Fram oil filter commercials from the 1970s, “You can pay me now, or you can pay me later”? That logic is the same for software evaluation and implementation. If you don’t do the proper planning, then you may hit a point where you may have to abandon the implementation and revisit the entire software selection effort.

Years ago, a large retail operation in the Southwest hired my consulting firm to lead it through the implementation of a just-purchased software product. We started the planning process and by the second day of discovery, I began asking very pointed questions about their newly purchased software, things that would ordinarily be part of a retail package. I received the answer “I don’t know” quite a few times. At the end of the session, it was obvious that they really had not contemplated all of the operational needs in their organization.

The project was kicked off, but in my head and heart I knew it had a small chance of succeeding because the client was not ready for the change that a new software package was going to bring. They had not defined their requirements and accordingly had no idea if the package would be up to the task.

As the project went on and I exhibited some “tough love” to my clients, they became increasingly agitated about where things were going. It culminated with me telling the business owner (where was he during the “selection” process?) that he just wasted a bunch of money and needed to create a team with representation from every area in the organization to aid in a new software selection effort. I told him he needed to go slower so he could finish faster.

If you scrimp here and try to pick the software vendor in an organizational vacuum, you most likely will get backed into a corner at some point. The chance of getting a software solution match is directly proportional to the amount of effort an organization spends in planning the evaluation and in seeing that every functional area within the organization is represented in the process.