The Five Top Reasons Why IT Doesn't Innovate

By Laurent Duperval

(Back to article)

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.

Seeking perfection: As Dr. David M. burns said: “Aim for success, not perfection.” IT often pushes back on new, ready implemented ideas because they aren't perfect, or they don't answer all of the needs immediately. In many cases, that adds unnecessary delays to projects that could be completed much faster by adding new functionality as needed.


Recent Microsoft Windows releases illustrate this very well: in order to

prevent more delays in XP and Vista releases, Microsoft decided to remove certain planned features because it took too long to implement them correctly. They forfeited perfection (e.g., all announced features) in favor of success (e.g., a new product out the door). This is a core tenet of agile programming—you don't need to get it exactly right the first time. Set the ground work, implement the core features quickly in order to get early feedback. Then adjust according to the feedback.


In the course of seeking perfection over usefulness, IT may be perfecting something that the user does not want; making those efforts perfectly useless.


Not part of our mandate: When people are hired at Google, their managers are told that they should not book more than 80% of their time. Google offers their employees the ability to spend part of their time working personal projects. The idea is simple: somebody is going to come up with a bright idea that will help the company. By most accounts, Google stands out as one of today’s most innovative companies.


Yet, in most companies, management disapproves and discourages any type of unassigned work. Employees must work only on approved projects, and on specific tasks that have been dictated to them by their superiors. The problem occurs when the work that has been assigned is tedious or disliked by the employee.


People get motivation from the work they do. Bonuses, extra pay and other devices may help a little, but most of all people remain in their jobs because they like what they do. Giving them time to work on other things ensure that every week employees work on something they love and are passionate about. By doing so, you increase employee retention rates by keeping their motivation high, and you can reap benefits of seeing new ideas added to the corporate mix.


Companies that wish to survive into the next decade must come to grips with using innovation as a tool for success. Some of the best ideas will come not from management, but from IT programmers, clients, or other outsiders. The IT teams that will be seen as most valuable are the ones that are able to quickly apprise, investigate, and test such innovations in order to best serve a company's vision, and most of all, its clients. 


Laurent Duperval is the president of Duperval Consulting which helps individuals and companies improve people-focused communication processes. He may be reached at mailto:mlaurent@duperval.com or 514-902-0186.