A recent newspaper story recalled the plight of a software enthusiast who created an application that allowed users of a transit system to check bus schedules on their mobile phone. The transit company does post the schedules on its website, but they are unreadable on mobile phones.
The application developer brought his idea to the transit corporation, but it was turned down. The reasons? Different priorities were scheduled and the idea could not be implemented for a few years. Furthermore, the application was lacking a few features that the transit corporation was planning on developing itself … someday.
Unfortunately, this story is typical of many ideas and projects that are submitted to IT. In discussions with various people who need to deal with IT, a refrain often comes up: “IT does not listen and is not responsive to new ideas. The only way to get something new through the door is to get buy in from other departments such as sales, marketing, or finances. Once other departments make the decision, IT has to work with them in order to get the project completed.”
Why is it so difficult to get new ideas and processes into IT? Here are a few reasons:
Not built here syndrome: Some people in IT are notoriously opposed to anything that comes from the outside. There are multiple reasons: the risk of malware infiltration, the added burden of supporting extra software, no control over the quality of the code, etc.
While these may be valid reasons, another reason is often afoot: ego. Ideas are rejected, not because they are bad, not because they are not implemented correctly; they are rejected because IT did not come up with them first. Or sometimes, IT is already considering an implementation of the idea, so the external version is seen as a superfluous.
Instead, these external ideas can be used to jump-start an internal implementation of a similar process. While the existing implementation may not be suited to the overall architecture, it can be used as a proof of concept. Better yet, by working with the person or people who completed the initial implementation, IT can get valuable information about pitfalls to avoid and issues to consider.
The customer is not the most important client: Too often, IT sees the network and the systems as the client. New endeavors are considered mainly on their coefficient of cohabitation, e.g., will they play nice with what already exists? Anything that is too disruptive is frowned upon because it adds an extra burden to an already overworked team.
If IT is to be seen as a partner in the business, and not as a service counter where work orders are dropped off and picked up, it needs to focus more on the needs of the clients and less on its own needs. Sometimes, disruptive technologies are just what are needed to make things easier and more useful for the client. Lest we forget, the client pays our bills and puts food on our tables.
Insufficient resources: Cutbacks, layoffs, outsourcing and other economic factors have severely affected the size and composition of IT teams. Innovation requires time investment as well as human investment. IT can get it done. Let’s be honest, most teams are knowledgeable and competent, yet every year they are asked to do more with fewer people. This is not a viable long term approach. Corporations will need to allow IT teams to get larger in order to support more eclectic systems, if those systems are better suited to serve clients’ needs.