10 problems with switching your market research software

Have you considered changing the software you use? If so, have you looked at the 10 biggest problems with switching your software? You might be sure that you need to change the software you use but it’s easy to postpone the decision. Is that the right decision? This article looks at the problems with switching to another software solution. Although it is applied to the market research industry, most of the factors apply to any business sector.

1. Testing is too time consuming

Does a trial work?

When moving to a new software system, most buyers like to take a trial. To make an exhaustive test of the software is time consuming and, arguably, impossible. The question is, therefore, “is there a better to evaluate a software product?” As users and prov

iders of software, I feel that the most success is achieved by our 7 Step Software Evaluation Approach.

Make sure you have enough time

Software trials take time. There’s no point trying to do a software evaluation if you or your team are too busy to spend the time to assess the software properly. If you don’t have time to follow the 7 Step Software Evaluation Approach, leave it until you can give the time it needs. If you are going to lose more business than you wish because you do not make the change, you just need to find time.

Keeping it focused

This step by step approach minimises the time you and the software vendor need to spend. If the product is not a good fit, it is better to know this quickly. Good software suppliers will tell you what are the pain points and which things may not make their product the right fit or a compromise. At the end of the day, you are making a business decision – does the money you spend on the software equate favourably with the business you wish to conduct? It is as simple as that.

2. Learning takes too long

Allow enough time for the transition

Evaluating and allowing sufficient time to learn a new software platform is an important part of the process. The time that this transition takes will vary substantially from product to product. Make sure you have a proper conversation with the software supplier to understand the training process.

The training – simpler software products

I have found that products that are easy to use with clear and singular or limited functionality are most taught by having a workshop session – this may take anything from one hour (or even less) to two days typically. If there are a larger number of people to train, two smaller groups may be more expedient.

The training – more complex software products

For more complex software products or for products with multiple functions or modules, greatest success is usually achieved by having a small number of people who can become product ambassadors. They can become the experts so that they can teach others in whatever way suits the company or team’s structure. Alternatively, it may make sense to have different individuals focus on different functions or modules of the software product.

3. Old projects need to be moved

Moving projects to the new platform

This is easy to underestimate so a proper evaluation of how painful this will be needs to be made. It is possible that the old software needs to be run in parallel for a while. Problematic projects in market research tend to be tracking studies or projects that are repeated periodically, for example, each year. If every project is an ad hoc project, this will not be an issue unless you need to re-analyse or re-use old projects.

Tools for moving a project

It may be reasonably easy to move much of a project. Triple-S, for example, is an interchange format that allows you to export a project from one system and import to another. Most good software products are Triple-S compliant. However, this may not transfer the project in exactly the form you need, so it is worthwhile discussing such projects with the software vendor. However, Triple-S is a good interchange format for moving all the texts from one product to another.

What about the data?

Triple-S will also transfer data between software packages, but there may still be some need to recode or reformat data. Systems that use proprietary data formats are the most difficult to ‘escape’ from. Using SPSS as an interchange may be possible, but if your data is trapped in a legacy system, this may be an unwelcome problem that needs to be addressed.

4. Transitioning to new software is difficult

The transition

My experience of transitioning from one software product to another is that there are three stages. These are: a) Finding your way around the new software b) Becoming competent in the new software c) Becoming highly productive in the new software. The goal, of course, is to reach the third of those stages as fast as possible. Planning a step by step approach regardless of how simple the product is to use will ensure a smoother transition.

Staff skills

Staff capabilities may be an issue. If you are transitioning to a higher level product to meet client needs, for example, staff may need extensive re-training or struggle to meet the new demands. A good software vendor should be able to advise on what is needed – again, you need total transparency, otherwise it is not going to be a good client-supplier relationship.

5. The new software might disappoint

When you are enthusiastic about change, it is easy to overlook an important detail that might make the change a mistake. A good software vendor, in my view, should be ready to look at your projects and assure you that your needs can be met. If this is especially onerous, it might be wise to do two things firstly, get assurances from the software vendor in writing and, secondly, be prepared to spend money with the software vendor for consultancy. A recent buyer of MRDCL came to us with 8 or 9 projects that they wanted us to review to ensure that everything could be handled. This required us to do a substantial amount of work, but it reassured the buyer that they were making the right choice.

6. The new software costs more

If you are moving to be a superior software product, it is likely to cost more (though not always!). I have been asked to match the price of a substantially inferior product on more than one occasion and each time I have usually explained that the small price difference will pay for itself many times over. Your decision should be a straight business decision will I get more business/do my business more efficiently if I spend the extra money. If the answer is yes, buy. If not, dont. It is as simple as that, I am afraid.

7. Only some projects are a problem

There are times when switching to a lesser product that is cheaper is the right decision. I can cite two examples. Such a decision can reduce your costs dramatically.

Using a lesser product for most projects

I recently spoke with a potential customer that was running online surveys in Confirmit. Confirmit is a quality, high-end product but the cost per interviewer is many times higher than a product like Snap. The customer agreed that over 90% of their surveys could be handled just as efficiently using Snap. In fact, as Snap is a far easier product to use and needs less skilled staff saving yet more money. Id like to say that the potential customer bought Snapfrom us, but they took my advice and bought an alternative product. However, running Confirmit and the other product side by side reduced their costs dramatically.

Separating project types and considering outsourcing

I encountered another example, which is similar to the previous example but offers a different solution. One client thought about purchasing MRDCL from us, but it transpired they were buying MRDCL, a high-end tabulation software product we provide, because they needed it predominantly for one big, difficult project. I recommended that they bought QPSMR from us as it would handle all their projects with less skilled staff at a cheaper cost and paid us to handle the complex project for them. The cost saving was again substantial plus they were able to leverage our expertise to handle the difficult project in the most efficient way. The saving in software and salary costs was substantial.

As I have stated several times now. It should be a business decision based on the work and team you have.

8. Staff are resistant to change

Theres a popular expression that no one likes change. I find myself at the other end of this spectrum and always want to consider change and, if it makes sense, make that change. I am part of the philosophy as a business owner that if I dont improve my business, someone else will do it and overtake my business. Staff can be resistant to change. Its obvious why. Staff do need to be considered and be on board where change is needed. Discussing with staff how to make the change works better than imposing change.

9. The new software has one disadvantage

This is the most frustrating knock back that I find as a software supplier, so I am going to deal with it head on! Ive received emails from companies trialling our software saying that they are delighted with everything cost, improved productivity, features.everything but one minor function of our software is not quite as good as the current software. That may be true and, if its something we can fix, we will try to fix it, but it shouldnt be a deal breaker. Any software transition will have pluses and minuses. You just need to be sure that the pluses outweigh the minuses significantly and that none of the minuses actually stop you from doing what you need to do.

10. Confidence about the new supplier

I think this is an important one that you shouldn’t ignore. If you have any doubts about a software company’s ability to support you or provide you with what you need, you may be choosing the wrong software. I can only advise that direct questions should be asked and guarantees sought if it seems necessary. The company behind the software is just as important as the software itself.

In summary

• Decide on and follow a step by step approach
• Only take a trial if you are ready to carry out the trial properly
• Be prepared for implementation if the trial is successful
• Follow the 7 Step Software Evaluation Approach
• Plan transition to the new product
• Consider problem projects
• Consider different ways of working/handling projects
• Do the arithmetic – what cost differences do you anticipate?
• What are the benefits?
• Get staff on board
• Get adequate training
• Check that you are confident about the software supplier

We can help

If you need help with considering our products or any software decisions that don’t involve our products, we are ready to help and make that change as painless and profitable as possible for you. Contact me by email for help.