I’m going to take a stance that may be fairly controversial, so bear with me and let me explain. It’s all driven by this wonderful post on Smashing Magazine My stance…

Customers shouldn’t have the ultimate say in the software or vendors they use.

There. It’s out in the open. Some people may be nodding in agreement, others may be lighting their torches and sharpening their pitchforks. But, before you angry ones attempt to burn me at the stake, let me qualify.

Customers are out of touch

My customers aren’t particularly “tech-savvy”. Actually, saying most are “tech-illiterate” is a pretty safe statement. It’s a blessing and a curse. I look at their lack of knowledge and see that the solutions we’ve provided them were built in a way that they don’t need to concern themselves with the intimiate details and design. But there are also some potentially large problems that can arise with this scenario; one of which, I’m working through right now.

My customers don’t understand how things actually work. They click a button, something happens, and all things seem right with the world. What they miss out on is all of the business processes and logic that that button press performs. At some point in time, these processes and this logic were defined - they needed to be in order to be built into the application. But because the customers only deal with them once in a blue moon, they forget they are there.

Time to replace the status-quo

This is where that problem outlined above actually comes into play. For some reason, the current software doesn’t meet expectations anymore. The customers want to do more and the software is becoming a limiting factor. They decide that, as internal developers, it isn’t cost-effective to have us build something new or rework the existing application. So they start gathering a list of vendors and send out an RFC. But instead of including the developers in the vendor demos and ensuring that the correct things are being reviewed, we were left out because “we don’t want to get into that conversation during the demo”.

The demos were poorly conducted. There was (from my understanding) very little scripting for the vendors to follow, questions about functionality were very shallow and had little in the way of substance, and (again, from my understanding) the primary focus was on the design of the UI. Most of the questions asked were answered by the vendor with the statement “Of course we can do that.”

A vendor was chosen, specs gathered, and requirements written. All was thought to be right with the world. Until half way through the project, that is. All of the sudden, requirements were incomplete or missing; the customers all had different understandings of how everything should work and none of their understandings matched how the vendor’s product worked. The budget was blown in a heartbeat and the vendor began billing for customizations galore.

Maybe the customer doesn’t know what they want

The most recited mantra of this project has been “if we knew back then what we know now..”. But what everyone fails to realize is that the dev team that supports them had all the knowledge they were missing. We should have been included since day 1. I can honestly say that I believe moving to a vendor-based solution was a bad call. They wanted something that was easy to use but needed to be customized to the “nth” degree to fit how they wanted it to work. That alone negated most of the benefits gained by using a SaaS solution. I’ve built a mostly-functional alternative in a fraction of the time of this project and it works correctly for the people that need to use it. Unfortunately though, it will be shunned and eventually thrown into the dustbin for something that is frail and held together by workarounds.