I’ve been doing a lot of reading about human-computer interaction and how you can use the science of the brain from both a physical and a psychological perspective to improve the way that computer programs make individual users more productive. In the course of my study I came across an approach to usability testing called the “Wizard of Oz prototype.” Simply explained, this is when a piece of software is tested for usability but is not yet in a fully functional state. The prototype appears to the user to be fully reacting to their inputs, but in reality there is a “man behind the curtain” that is controlling all the behavior reflected back at the user.
I have seen this scenario happen in a real life environment during software demonstrations from a well-known competitor of BMC’s in the SaaS ITSM space. You’ll see a demonstration going on in the front of the room and your eye is drawn there. You ask to be shown some functionality and are deflected and promised that it will appear later in the demo. In the meantime, there are some extra individuals at the back of the room or in a remote site furiously coding to make it appear as if something that took a “wizard” to develop is really easy and out of the box.
One way you can be sure the software package you buy isn’t being controlled by a “man behind the curtain” that won’t be available to you after the sale is to try the software solution yourself – alone. This way you can see what is truly out of the box and what is not. Many times even the trial you get from a software vendor will have “extras” built into a trial environment that are not part of the product or service you’ll receive when you sign the contract.
So, how do you perform an objective test? First, be sure you are getting a truly blank slate. Ask your prospective vendor if the trial is identical to the software you will receive or if it has been built as a marketing tool. Anyone who has ever compared the picture of a Big Mac on the menu board at McDonald’s to the one you get in the box will understand the difference here. You can then examine what an “empty” instance of your ITSM tool will look like.
Next, ask what best practice content is available for you to load – and be sure that same content will be available to you for your production environment. Then, load it yourself. This will give you the experience of doing something administrative to the solution that will give you an indication of the complexity of administration for other parts of the tool. If it’s overly cumbersome, you know that some team of “wizards” spent weeks building that demo to sell you on the flashy floor model – and that you have a long (and probably expensive) road ahead to get that same capability in your own production environment.
This is one of the reasons I’m so proud to work with BMC Remedyforce. Our trial environments are identical to the ones you’ll get when you become an official customer (with the exception of some limits on user counts, etc.). We provide you with “Smart Practices” content that you can load on your own through a (dare I say it?) wizard available to you right on the Getting Started page. You can see on your own how easy it is to take advantage of workflows, service request definitions, service levels and more that our team developed based the best configurations of hundreds of Remedyforce customers we examined. You can even load some sample data or use your own to see what a fully populated, in-use system looks like – and if it will work for you.
No smoke and mirrors here.
So I encourage you to take a trial of BMC Remedyforce – and to take a look at who’s in the room or behind the scenes the next time you’re getting a demonstration of other products on the market. Be cognizant of manipulation and you’ll be much more satisfied when you make the right choice for your organization.
IT Sparks 