How to quantify the advantage of using JMP over other tools to convince the management to consider it for usage?

[#1]

Dear community, 

we all know how great JMP is: efficient, interactive, powerful, ...

How would you make others, mainly management (the team itself is interested)  to consider using it? Especially when there are almost free available alternative software (incomparable with JMP) and exactly for that reason the management wants to continue going with it. The argument: "It is great because I know it" is not convincing. How would you quantify the advantage of JMP? Which metric would you consider to calculate the ROI? 

I would be happy to hear from your experiences. 

Merci! 

[#2]

Very well said! I appreciate! 

[#3 · Accepted solution]

I am thinking of complementing what @Mark_Bailey and @statman said with an experiment or two.

Starting with picking a common task which you and your colleagues need to do quite frequently, as they suggested.

Let me use fitting and analyzing linear regression models as an example.

Step 1. List the steps that you need to accomplish the task by using JMP. And list the steps that you need to accomplish the same tasking using another software of your choice.

Step 2. Start timing how long each approach would take for you and your colleagues to finish.

Step 3. Change the data set, go to Step 2.

Repeat Step 2 and Step 3. To see how much difference between them. If there is difference, then in the end, use what @SDF1 suggested to convert time into money. You may have to try some different tasks to be fair, I guess

The above experiment is for some repetitive tasks. Now try some spontaneous tasks. For this experiment, you have to find two individuals who are experts of the two software that you are comparing. So one is a JMP expert, the other individual is specialized in the other software of your choice. Now pick some non-trivial tasks. For example, some kind of predictive modeling. The assessment includes at least two parts: (1) timing (2) accuracy. What you are going to observe will be the achieved accuracy under the same time constraints. Or you may observe the different time consumption to achieve the same accuracy. Seems like that the second measurement might be easier to convert the difference into cash. Probably have to try several different tasks to be fair as well, I guess.

These experiments will reveal things that you need to consider more or less similar to what @ron_horne pointed out.

[#4 · Accepted solution]

Invite them to watch this video:

Then make them think how many secrets @calking could reveal in your company's data.

And just before they decide to hire him: show them how easy it is to create such graphs and drill-downs on your own in Jmp.

Then Caleb can stay with Jmp and you get the Software

[#5]

In addition, don't forget "the other side of the scale".

The availability of a single feature can have a huge impact on decision making - especially if a feature is just available in the current software and missing/different in Jmp. A tiny disadvantage/bug/misfunction can balance many benefits.

Think where Jmp could be optimized - and write a wish:

https://community.jmp.com/t5/JMP-Wish-List/idb-p/jmp-wish-list 

Scan the existing list and give Kudos.

Let's empty "the other side of the scale" and make Jmp the one and only choice for your company

Sometimes, it's a tiny thing (a "bug" or even a feature, which cannot be disabled) which can reduce the usability of Jmp:

- outdated JSL editor

- overzealous state handler

- heatmaps which forget to show 1 value per chip as soon as the user changes the zoom

- jsl code which cannot be executing because the user renamed a column

- fonts which cannot be adjusted

- color scale (gradient) settings which need 4 mouse clicks to be adjusted (just compare the cool axi...
- crowded axes - empty plots

It's good that for some of the bugs in the list there already exists a workaround.

But work will be really great with Jmp 18  Jmp 19   and all of these bugs fixed

[#6]

---

@hogi wrote:

In addition, don't forget "the other side of the scale".

The availability of a single feature can have a huge impact on decision making 

---

... and Jmp should put as little weight as possible "on the other side of the scale", e.g. hiccups of the user experience like

how to disable it?

[#7]

I second this solution