Good software can flunk if it’s badly demonstrated. This is common sense but something I learnt only recently was the importance of data in the user’s perception of what a good software is.
When I did the sales demonstrations I’d used demonstration data. It worked, the buyers placed the order and I was then asked if I wouldn’t mind demonstrating the system to the end users.
Part of the bid involved importing the customer data and I was about half way done so I thought it would be cute to show the end users their own data.
In retrospect that was a big mistake.
When replacing a core system, something that the users spend most of their time with, they’re naturally going to be a little cautious. I was very aware of this so I attempted to mitigate it by saying that there may be a few little holes as the data import wasn’t finished. Sure enough one of them spotted a data error which I attempted to brush aside, but they wouldn’t let it go and it was followed by an avalanche of questions – unsurprisingly the users knew where the complex data was – the bits that I hadn’t yet imported. End user confidence utterly nosedived and optimistic caution went to out of hand rejection. It was a very difficult session, especially when you have people saying directly to you – and I quote, “Your system is shit. We can’t use this shit.”
The fact that I had demonstrated everything that they needed to do, had demonstrated that it was easier and clearer with our system than the one they had and that we gave them a heap load of extra functionality stood for nothing because the data behind it was poor.
About the same time a failing government project to replace the many disparate control room systems in the Fire Service with one package was being lambasted in the press. The entire history of the venture pretty much reads like a manual on how to screw up project – critical mistakes were being made left, right and centre. All these reasons are complex and somewhat intangible. What the press had picked up on was that a supposedly national system only “knew about” one small area of the country – Wakefield I think. That’s tangible, that was something people could understand. That’s what people were laughing about and of course it was a problem, but it had precious little to do with the failure of the project.
So a hard lesson for me to learn that people just don’t seem able, or perhaps willing, to separate the concepts of data and functionality when it comes to software. It took months of hard work after that bad demonstration to get the users on board.
It is very important to get them on board early in a project and keep them informed, you want them to feel like they’re involved – part of the process – then acceptance of the system is much easier. Until you’re confident that their data is 100% though, use demo data.