This morning I was reading a blog from Dave Litzenberg titled "The Scripted Software Demonstration: Making an Enterprise Software Decision on More than Gut Feel" - http://tinyurl.com/qoegsx - and I had to make a couple of comments on scripts, and why they are not the greatest thing since sliced bread.  Scripted demonstrations are great for creating structure - but it has a couple of downsides.

The customer only sees what they think they need.  In this fast changing environment where there are new technologies and techniques that can be employed by customers - a script is going to force the ERP vendor to show exactly the same things that the customer has right now, and they will remain in the same rut that they are already because they are not allowed to see differentiating features from all of the other vendors.

As a sidenote - if the consulting partner does create the script for the customer, then that's great - as long as the customer knows why it's important.  There have been many situations where we have been demonstrating (as you've probably guessed I work on the other side of the table) and we ask - "Why is this important?" toi gather more information - and the customer has no idea.  The selection partyner may, but we just get a blank look, and then all scoring goes out the window.

With scoring, make it simple - either the product works, or it doesn't.  There is no need to have complicated scoring from 0-10 or other wide ranges - because the users that are scoring are not able to judge with great accuracy if that was a 7 out of 10 fit, or a 8 out of 10 fit.  This is not neccessarily for the software vendor, but just a mercy ple for the poor people scoring.

Be realistic with the script as well.  We have come to demonstrations where we have had a 700 point script (not from you all) that we were asked to do in 4 hours.  We can't even read the script in that amount of time - and rushing through the features is of no benefit to the customer (who really just sees a flurry of screens) or to the vendor (who never feels like they have done a good job).

Also, be flexible with the organization of the script.  All software products have an ebb and flow that makes them unique.  When you try to divert them, or twist them in ways that are unnatural to the product, then they look clumsy.  When you can show the workflow in the way that it was intended (and that the users would use the product), then the education process works much more effectively.  A suggestion to all of you that are creating scripts may be to break it up into bite sized chuncks that can be re-arranged to fit the demo.  We (the vendors) will get to all the points, just not in an order that is unnatural.

Finally - a plea to the Selection Vendors.  Educate all of the users before the demonstration starts.  Software vendors hate going first, because they spend all of their time teaching customers what ERP is, or why they need to trace their products through the lifecycle, or why process manufacturing is different from discrete.  There is a myth that the first people in the demos loose because people forget about them after 3 other demo's.  I don't think that's the case - I think that it's because they spend all of their time discussing and educating customers on the process that they are about to embark on, and don't show enough product.

I'll get off my soap box now :-)