We recently helped a client make a system selection. They got several good proposals, scheduled a manageable number of demos, and it came down to two strong finalists.
To our mind, it was a clear choice. While both vendors were great companies, one vendor had a system which already met 80% of their needs, really understood the complexities of their business, and had a support model which was extremely personal and responsive (a view that was supported by the three reference checks conducted). The other vendor would have had to have done a lot of customization, in an area that wasn’t their core capability, and had a support model which was more arms-length. We went into our final vendor evaluation meeting feeling comfortable that the first vendor would be the clear leader.
And then the sparkly thing danced in too.
The shiny sparkly thing is the amazing feature, the cool technology, the moving graphics or instant data, and it causes Shiny Object Syndrome, where your colleagues and leaders see something cool and they want it. The glitter of the shininess blinds them to reality.
In this case, the second vendor had one of the coolest reporting interfaces we have seen recently. During the demonstration we all actually said ‘ooooh’ when the data just flowed into a beautiful dashboard. When we met for a review meeting, our client talked about the great reports they could create with that system. But reporting was not one of the areas that our client had prioritized through a rigorous review of operations and requirements.
The main question is: Which vendor’s approach and system will best support your critical daily operations.
So you have to select for what you know, the things you need to do today. Don’t select for what you think you’d like to do in the future. We’ve heard clients who say that they picked a system that was bigger than their needs because they thought they would use the certification module or the event module or the subscription module, but in the end, it didn’t quite fit. Their requirements had not been clear at the time.
It is better to pick what you know, and develop software to suit what you need right now. Certainly, leave doors open to the future. Have an idea of what you’d like to do and if your new system covers them, that’s a bonus. And certainly ensure that the software will last you a few years by checking that the code base is current, the system is upgraded regularly, and they have a roadmap for integrating new features.
But you will get lost in the boggy marshes of failed software if you chase those sparkly things into the night.