When to switch to scripted tabulation software like MRDCL?

With over a hundred crosstab software packages, including QPSMR, available to the insights and market research business, choosing if and when to upgrade to a powerful tab software product like MRDCL is a tough decision. It’s a familiar question we hear from users of the QPSMR software we sell, but it’s equally applicable to anyone producing tables in more basic tab systems or platforms with a crosstab module or function.

About this blog article

You will learn five things from this blog article:

• Good reasons to move to a scripting language like MRDCL
• Bad reasons for moving to a scripting language like MRDCL
• Things that will become easier
• Problems you will face
• Paths to success that work

Before we start

Let’s start with some basic facts. Firstly, there are few specialist scripting languages available for crosstabs. Most are outdated tools like Quantum, Merlin and Uncle. Whilst they have good functionality, they have not been updated recently and, in my view, fail to meet modern computing demands. For example, Quantum’s analysis tools have not expanded to the best of our knowledge in twenty years. Secondly, most tabulation software systems use friendly user interfaces, which only become difficult sometimes due to the bewildering number of options that may be hard to find. Upgrading to MRDCL will mean some initial pain and a commitment to learning – in the short term, at least.

Five good reasons to use MRDCL

So, the big question is, ‘When is it right to move to a powerful scripting language like MRDCL?’ Here are five good reasons; they are not an exhaustive list, but hopefully give you some idea of when you should consider such a move – they are in no particular order:

• The software you are using struggles with a tracking study, which may have frequent questionnaire changes
• The analysis you need is too complex for the software you use
• Handling repetitive needs (simple or complex) is cumbersome, time-consuming or prone to error
• It takes too long to get data from your data collection platform/provider to your analysis software
• Things that you feel could be automated are a manual process

I could add a sixth one. It’s when you get a gut feeling that there must be a better way, but let’s look at each of these in a little more detail.

   a)Tracking studies

Tracking studies ought to get easier to handle over their lifespan. For most research tasks, they do, except, that is, for data analysis. Problems compound for data analysis, making the task of producing results slower and slower or more and more prone to error. Most menu-driven crosstab software cannot handle questionnaire changes well. For example, additional questions, deleted questions, additional responses for questions, changing brand or sub-brand lists, changed data outputs or formats and other superficially minor changes. MRDCL has a whole range of tools to manage these things efficiently. For QPS users, there are tools to convert tracking data to its most recent format, but this can be an awkward operation in many cases.

    b) Complex analysis

I don’t like to be vague here, but every menu-driven crosstab software package will have a weakness. Changing to another menu-driven crosstab package will likely mean you will face a different deficiency. Menu systems, by definition, give you options to choose from. If your precise needs are not available as an option, you usually have to face an unwieldy workaround or an inability to produce what you want. Here are some examples, although there are too many to mention here:

• Summary tables from rating scales are problematic.
• Specific statistical options, such as significance tests, are unavailable or have limited variants/options.
• Multi-response questions are only available as a series of single-response questions.
• Numeric questions are difficult to work with.
• Ranking the rows of a table is difficult or impossible.
• Target and rim weighting methodologies are not available or limited.
• Hierarchical data or data loops cannot be handled efficiently (e.g. trips, meal occasions, items bought)
• Plus, many more.

    c) Repetitive needs

Some things are conceptually easy but painful to implement. Let’s say you have a series of 50 rating scales and want to add a top two box and a bottom two box to each statement. Is this one operation or 50 operations? What if you want to create ten new variables showing awareness of ten brands within age and region? Is this one instruction or ten repetitively generated tasks? Not only will MRDCL save you time, but the risk of making an undiscovered error increases significantly with lesser products.

    d) Preparing data

Ideally, you want to take data from your data collection platform or provider and have the data instantly ready for analysis. While this may be idealistic for every project, it is unarguable that the less time this takes, the better. Anyone switching from QPSMR to MRDCL will not have this problem, as the two products use the same engine. However, I have seen data processing staff spend hours converting data to be usable in its tabulation software. And what if the data needs to be re-read due to a minor error? Is this a button press to update, or does it necessitate a repeat of several hours of work?

    e) Automation

If you have a tracking study and want to run three sets of tables with annual data, the last three months’ data and the current month’s data, all with different banners, is this one button press or three separately prepared runs? What about if you want to read in some SPSS data, produce a standard set of tables – or, perhaps, some tables with varying parameters – after which you want the data automatically exported to another format? These are, of course, just examples, but automating processes can be an important consideration.

Five bad reasons to switch

I am sure there are more reasons, but here are a few:

• You are too busy to invest the time to learn more efficient methods. Sure, there is never a good time, but staff need time to learn the tools that will bring the most benefit.
• Your current systems work efficiently.
• You don’t have staff skilled enough to learn a scripting language or with some previous relevant experience.
• You are not committed to change – MRDCL will usually bring efficiencies, give you more choices and empower you to meet client needs better, but without commitment, it will not work.
• You expect gains within two months. After one year, we expect suitable users to see benefits; after two years, we expect significant gains, including cost savings.

Paths to success

Changing the way you do anything always involves some pain. Switching to MRDCL from QPSMR or similar products can be less painful if you follow our four-step guide. Firstly, though, let’s look at the particular case of changing from QPSMR to MRDCL, as these products are from the same family.

Moving from QPSMR to MRDCL

(Skip this bit if you’re not thinking of migrating from QPSMR to MRDCL)

It’s worth a moment to understand how QPSMR works and uses the MRDCL engine when processing tables. When you run tables in QPSMR, the program reads your QDF (questionnaire definition file) and QTF (QPSMR tables file) files and generates an MRDCL script. Without necessarily knowing it, QPSMR then runs the MRDCL script and displays your tables. In other words, the MRDCL engine does all the processing, calculations and table formatting. This means that QPSMR will generate an MRDCL script file in a file with a .stp file extension. You could run this .stp using MRDCL and achieve the same results. However, QPSMR only gives you access to a small percentage of the functions and features available in MRDCL. These functions and features expand what is achievable and offer possible major time and cost savings. The .stp file generated is a good way to start learning how to use MRDCL, as you can see what script QPSMR generates for you. However, QPSMR will produce shortcuts that MRDCL will give you.

The four-step approach to migrating to MRDCL

Step 1: Learn the basics

As mentioned above, QPSMR users have a slight advantage as they can learn the basics by comparing their work in QPSMR with the script generated in MRDCL. However, there is no magic solution to learning the basics of a new system – you need time. Fortunately, we have a programme of introductory videos that take you through the fundamentals with example scripts that you should understand. These have proved incredibly successful in reducing the onboarding process. Coupled with this step is to practise using MRDCL. MRDCL has a fussy syntax, but anecdotally, users find that by ensuring they are familiar with the basics, it soon becomes second nature. We have found that users who do not spend enough being comfortable with the basic syntax progress more slowly with the more advanced features.

Step 2: Learn scripted loops

One of the most regularly used power tools in MRDCL is the pre-processor. This set of tools allows you to script repetitive needs in a shorter way. For example, suppose you have 20 rating statements that you want to apply scores to each response and add top and bottom two boxes. In that case, this can be achieved as quickly as applying it to one statement. Research questionnaires often have repetitive sections, rating scales or similar tables. The pre-processor will drastically reduce the time you spend preparing and running the analysis. Additionally, you will reduce the number of errors you make. These tools are not especially easy to learn at first, but it is only a small hump, which, once crossed, offers big rewards.

Step 3: Appraise your business

The next step is an important one. MRDCL has an almost limitless number of tools that can improve your productivity, accuracy and what you can offer clients. However, choosing the ones that provide the most benefit can be important. I like to encourage new users to look at what sort of tasks take time, are most prone to error, or can’t produce the output you would like. MRDCL has tools to make custom templates for regularly needed analysis or calculations. There are some highly efficient techniques which may or may not benefit you. That’s why I always recommend that new users look at their pain points so that we can help you to learn what gives you the most benefit. No two users are the same!

Step 4: Use the power features

Learning how to use MRDCL’s power features, such as custom templates, will take some time to master. However, it doesn’t need everyone in the team to learn these more advanced techniques. By definition, a template means someone builds, and others can use – they just need to know how to use an easy-to-use template, which may take anything from one minute to ten minutes! It may be that you need to learn some of the syntax that is available within MRDCL. We have found that users learn more advanced features once they learn the basics. One key benefit of MRDCL is that the syntax is logically consistent, making it easier to progress than other higher-level systems. Further, MRDCL has no ‘black boxes’, which can make sharing projects difficult.

In summary

The path to making effective use of MRDCL does involve some commitment. However, the rewards can be huge. Our tried and trusted step-by-step approach, informative videos, and customer support ensure that onboarding is as fast as possible and targeted. If you would like an honest appraisal of how much MRDCL will benefit you, please make contact with nikki.sunga@mrdcsoftware.com.