Making the Right
Software Investment
Follow these guidelines to find software that fits your company's needs.
by Adam Kolawa, Ph.D.

July 13, 2005

There are many reasons why you might be motivated to purchase new software for your company. Maybe a part of your enterprise needs to run more efficiently. Maybe you are trying to improve productivity, customer service, or competitive rank in your market.

Whatever the goal and purpose of your software investment, your ultimate quest is to make a wise decision. I'll give you some guidelines that will help you search for software that fits your company's needs. I'll start with these three pieces of advice, which I'll expand on during the course of the article:

• Explore and narrow down your options.
• Assess your software of choice.
• Avoid any chance of failure.

Explore and Narrow Your Options
You will have plenty of options to explore. Be aware that once word gets out of your need and search for software, you will be bombarded with information. The overload of information brings with it a couple of challenges. The first is sifting through mounds of propaganda; the next is processing and evaluating all the information that the salespeople ever so persuasively present to you.

When it comes to salespeople, let's face it. Their ultimate goal is to make a sale. However, keep in mind that they also want to make you—the client—happy. They want to help you attain your goal, with their software.

Salespeople will pitch their software in a way that best meets your needs. Furthermore, they can easily do so because software is not tangible. Instead, it is vague, which makes it possible for salespeople to strategically stretch its functionality. Software that doesn't quite fit your needs can be carved into a form that does. So when evaluating software, you need to ask yourself, "Does this software really do what I want it to do?" We'll touch more on this later.

Assessing Software
So, how do you determine whether software you are considering is capable of doing what you want it to do? There are a couple ways you can assess software to ensure that it will satisfy your company's needs. The first is developing a proof of concept, which is common, but not necessarily a bulletproof means of attaining and fulfilling expectations. The second is purchasing a trial version of the software. This is certain to open your eyes to whether the software you are considering will actually be used by employees and fulfill your requirements. I'll discuss both of these options.

It is common practice for companies to develop, evaluate, and test a proof of concept. A proof of concept is an electronic replica of an interface that reflects a desired design. It provides evidence that implementation of a certain business model or idea is attainable because the design concept is evaluated and validated.

Generally, after a proof of concept is developed, evaluators and testers analyze and test the features in the software. They tend to be drawn to it visually and are apt to focus on its appearance and usability. Instead, they should focus on analyzing how the software is going to solve the particular problem at hand. We'll touch more on their analysis in a moment.

After the analysis of evaluators and testers is complete, they turn their reports in to you. Upon your review, it would not be uncommon for you to think, "Looks good. Let's go for it!" It is highly probable that the software itself is quite good. However, just because software is good doesn't necessarily mean it's the right choice for your company. So, what happens if you do "go for it" without evaluating the real thing in a real scenario? Most likely your attempt to implement the software won't succeed.

The biggest challenge with proofs of concept is that they are often badly structured. They don't truly represent how you want to put the software to use. Instead, a proof of concept usually concentrates on the software itself, when in fact it should concentrate on the application of the software. Further, it should concentrate on how it will solve your company's particular problem.

There is an old proverb that illustrates the challenge of proofs of concept: There once lived a man who had never used a pillow. He was apprehensive about using it because he wasn't quite sure how it worked. He knew the pillow was made out of feathers. So, as a test, he decided to take one feather and place it upon the stone where he laid his head to sleep. He thought, "If it works well, I'll use the pillow." The man awoke the next morning with a horrible pain in his neck. He concluded that if the feather didn't work, the pillow wouldn't work.

The point is that when you set up a proof of concept, it must have enough critical mass to help you draw an accurate conclusion. People often try to minimize proofs of concept. They try to control them and end up shaping them in such a way that they are too small or too restricted.

Here are some things to think about when it comes to this approach: How many proofs of concept are you going to have to go through before you see what you're looking for? Also, what are you trying to accomplish with the proof of concept? You don't want to waste time or money.

Now, I'll return to the analysis performed by evaluators and testers. The key to analyzing potential software in accordance to how it works within the processes of your enterprise is to be realistic. It is important for evaluators and testers to direct their attention toward the effects of the tool rather than the tool itself. The analysis that matters is proving whether implementation of the tool into existing processes can resolve the issue at hand. Here's what you need to do:

• Set realistic goals.
• Monitor the processes to confirm whether they are improving because of the implementation of the new tool (as opposed to the usability of the tool).
• Continuously measure goals until they are reached.

Analysis boils down to the answers to these questions:

• Is the tool unintrusive?
• Is the tool truly helpful?
• Does the tool increase productivity?
• Does the tool truly solve the problem at hand?

The answer to all these questions should be yes.

Implement Trial Software Versions
To ensure that your software investment decision is the right one, set up a trial version of the software that you are considering purchasing in a realistic environment with realistic goals and realistic expectations. Just as important, you should compensate qualified individuals to set up your environment and the trial software so that they have incentive to build it for you—correctly.

Even though a proof of concept is typically only tried for 30 or 40 days, you should give the trial period an adequate amount of time so you can determine whether the software truly satisfies your needs. Be aware that you probably won't know whether a software choice is the right investment until about six or seven months down the road.

By implementing a trial, you should be able to evaluate whether it actually does improve what you expected it to improve. If it does, then you have a clear indicator of a good investment. If it does not, you should move on to something else, because in the end, this software investment will cost you money and drain your resources.

Oftentimes, people remain focused on the proof of concept when implementing a trial software version. Do not fall into that trap! Instead, go about business as usual. In a true-to-life scenario, there won't be much focus on the software you are thinking about implementing. In real life, it needs to just be there—working on its own—fitting in just as it was designed to fit. It should complement your processes, not be the prime focus of your processes. There should be nothing awkward about its addition. The potential software should blend in with the process flow. If it doesn't, then you are not going to succeed.

Ultimately, if the software you decide to purchase does not mesh well with your processes or match your needs, you are setting yourself up for a lot of rework. Rework costs your company more money and takes up more of its resources.

Avoid Failure
As I discussed earlier, because of its intangible nature, software can be strategically stretched to accommodate requirements and specifications. Purchasing software that requires a lot of customization to match your needs is a catastrophic mistake. When you customize, you enter a vast world of your own—and the unknown. You take a chance of entering uncharted territory, which is a dangerous place to be.

You take the risk of encountering bugs that no other clients will experience. Along the same lines, you will also have low usage problems. Say, for example, you have custom features that are implemented as checkboxes. Ultimately, these are not "real" features because no other client has implemented such checkboxes.

Both of these scenarios have repercussions. It will probably take longer to resolve those unique bugs. In turn, it will take longer to resolve bugs that are unique to only your custom system. What's worse, custom features are more likely to have bugs because there is a higher chance that they are not as well-tested as other mainstream features. As a result, custom features are less reliable.

Ultimately, purchasing mainstream software is wise and highly beneficial. It isn't wise move to have the software stretched or altered so that it can solve your problems. Also, you do not want extensions, modifications, or customizations of software that you purchase. In other words, only use software for its intended purposes.

Furthermore, there is such a thing as too many wishes when it comes to purchasing software. If you have too many demands, you will end up with nothing. Software is designed with a purpose in mind. If software doesn't meet your needs, don't buy it.

How do you really know when you've made a good software investment? Reality is that good software is used every day. If you do not see employees using software and you need to go through a lot of hoops and pep talks to get them to use it, you know you did not make the right investment. On the flip side, you know you've hit the jackpot when you walk into the office or onto the production line and you see the software that you purchased running on employees' machines, and furthermore, you see that they are really using it.

About the Author
Adam Kolawa, Ph.D., is the chairman and CEO of Parasoft, which he cofounded with a group of fellow Caltech graduate students in 1987. In 2001, he was awarded the Los Angeles Ernst & Young Entrepreneur of the Year Award in the software category. Contact him at .