Technology decisions limited by ability to support users
Ever had a bit of technology your use dictated to you by an IT department? Does it not even come close to meeting your expectations or requirements? Is it usually web based technology that is letting you down? This type of problem stems from what I call a ‘square peg, round hole’ philosophy in IT – when decisions of what technology to deploy is based solely on the ability to provide support, not the requirements of the project and/or an analysis of features required by the user. It seems to happen far more often with web based technology.
In a conversation with a colleague over a beer I tried to understand why this happens. Sadly I still don’t understand why, but I do better appreciate the position of people that decide to hammer that square peg in. But I think it because they don’t understand or have an actual use for the web themselves (that is a totally different post).
I believe this happens in every IT department and it stems from the environment. IT finds itself in a situation with limited resources to hire new staff even though they are tracking time on/and tasks and there is an expectation that IT needs to support everyone regardless of expertise. There is a project or group or department that has decided to use a particular technology. Reality kicks in and the service end has to learn to support the technology so a decision is made to apply that same technology to others that have similar but not the same requirements as that project group.
What happens next is ugly. The clients expect something that usually different because they may want the same features but they would apply a different priority to the features they use/need. This influences their expectations on the total experience. Take a content management system (CMS) for example. One group might put a high priority on workflow management, another on user management, another wants a templating scheme, another wants a forum, and another group really wants a wiki. A CMS can do all these things but I can’t think of a CMS that can do them all as well or anywhere near as good as specialized software.
However, CMS vendors will promise support and the ability to meet the demands of the user. This pulls on the support strings of IT. Rarely, if ever, will you find a CMS that delivers to a diverse groups expectations. What happens is that any number of groups become disenfranchised with the software and the overall project of deploying that technology is doomed to failure or mediocre success at best. The CMS vendor comes off either not being paid and/or looking really bad. The IT department comes off looking unprofessional at best which puts pressure on them to produce, and the cycle continues.
What should happen is that the IT department assesses the features as well as the priorities. They evaluate the technology providers based on that clear idea of what are ‘deal killer’ features for people. If it reaches a thresh hold that makes it impossible to please even 70-80% of the clients then IT needs to break down the technologies and groups not force them all onto one.
The web offers the opportunity for this to be easy. Web services, web sites as your API, universal log ins, etc. all make it possible to integrate different solutions on the data level. Sadly I think IT still approaches web apps as black boxes that work in silos.
The moral of the story for anyone building a web based service is that to really be a hit with medium to larger organizations you need to offer integration and openness in your apps. If you can be the folks that develop the integration tools as well as offer your product you can likely charge more based on a successful track record. At least from where I am sitting 
