Sales reps want to sell you their "solutions"-that's marketing-speak for hardware or software aimed at a specific business need. Your challenge is to identify the problem you're trying to solve before you get ensnared by a sales pitch. If you don't do this due diligence up front, your "solution" will become your problem. I know-I used to be a software salesman, and I've worked with many customers to replace systems bought from someone else that just didn't cut it.
In the software business, it's common knowledge that a customer uses less than 50 percent of a system's features and functionality. Smart buyers make sure that the 50 percent their companies will use solves the problems they have today and the problems they'll have several years into the future.
How can you make sure software solves your problems rather than creating new ones? Take a hard look at your current business practices and what needs fixing. Figure out what challenges you face, then use this information to develop the requirements for your system. Do these three things before deciding what type of technology you need-and before you even think about meeting with vendors.
Figure Out What You Need-Not Just What You WantI bet that you have a food processor tucked away somewhere in your kitchen. If it's like mine, it's collecting dust. Why? You bought it because you wanted one, not because you really needed to make coleslaw for 30 people. The same thing can happen when companies purchase technology without doing a clear evaluation of their needs. I know of many companies that bought systems because they wanted a particular brand (you know that old saw, "No one ever got fired for buying IBM.") or because they wanted to keep pace with the latest fad. They wound up not using their expensive new systems because the systems didn't solve the companies' problems.
How do you figure out your needs? First, look at your present situation. Say you're the head of human resources, and your company doesn't have a central place for human resources and benefits information. When employees call to ask about their benefits, your HR representatives have to look through stacks of summary plan descriptions, rifle through the employee handbook or rely on their memory to find answers.
Ask yourself, What's wrong with this process? Be specific. Say to yourself, Not having a central repository means it takes human resources employees 30 minutes to answer each employee question, and it takes 20 days to train new employees.
Now that you understand what's wrong with the process, state your goals, and put them in terms that are measurable. This advice may sound obvious, but believe it or not, many executives don't do this before they pick a software package-a big mistake. I can't count how many times I've seen potential software buyers sit passively and let me run through my PowerPoint slides and demos without stopping me to ask how the system will solve their specific problems-another no-no. Let the vendors know your objectives and how you will measure the success of their technology-and make them show you how their technology solves your problems-because if you don't, I can guarantee that your goals won't be met.
Check Your Wallet And Your Schedule
Once you've assessed your present situation and determined your goals, you should list the challenges you face in selecting, implementing and using the new technology. The most obvious challenge is your budget. Another significant challenge is time. If you have a deadline, it will influence the technology you select because not all vendors can meet an aggressive implementation schedule. For example, one company evaluating HR software needed a system that would be functional in time for its special benefits enrollment period. The software had to be ready when the employees received their new benefits information. The company met its deadline because it knew that time was a major issue, and it raised it up front with the vendor. Meanwhile, another company I know of failed to make time a priority; it is still implementing the manufacturing solution it purchased two years ago.
When determining your challenges, look at what is unique about your company and your department. The technology you choose must be able to accommodate your company-your company should not have to change the way it does business to accommodate the technology. One company I know of has more than 300 health plans (an unusually high number) and 60 HMOs. This was a challenge when looking for HR software because very few HR knowledge-based systems were able to handle all of the company's plans.
Put Your Requirements In Writing
After you have figured out your goals and challenges, list your system requirements in order of importance. Every need and challenge can be distilled into a requirement that you can give to a vendor as part of your request for a proposal. But don't forget the requirements that are not tied to your goals and challenges. If your company has standardized on Sun Microsystems Inc. servers that run Solaris (Sun's version of the Unix operating system), make sure the software you buy runs on Solaris.
Look for constraints in your environment. Must the new system integrate with existing enterprise resource planning software? What about with other software that your department or your company is planning to roll out next year or the year after that?
Don't forget about the people who will be using the technology. If they are not computer savvy, ease of use might be a requirement. Surveying the people who will use the system-or will be customers of the people who will use it-is a great way to find out what is important to them. At one company, a survey showed that employees wanted accuracy and responsiveness from the HR department. This need became part of the criteria used to evaluate HR software.
Don't Get Sloppy Or Lazy
Failing to do this prep work can waste time and money-and can even create new problems. One company I know of did a great job of listing its needs, but it forgot one key requirement: the fact that the company's customer service department was growing exponentially. As the company grew, the system was unable to grow with it. Eventually, the company had to migrate to a system with a back-end database that could handle the additional users-an expensive move that could have been avoided had the head of customer service done a little more thinking about his problem up front and identified system scalability as a need.
This early due diligence may sound like drudgery. But it isn't something that you can just hand off to the IT department. No one there knows your problems better than you do.