Why IT says no to innovation
Pity the IT manager. He (or she) is increasingly under pressure from product managers, business line leaders and others who want "innovation". Whether that's more data, or more insight from their data, or perhaps the product manager wants to deploy a new product - innovation is a constant demand. And while the IT folks would love to support innovation, they more often than not say "no". Who, in this day and age, can possibly say "no" to innovation? Meet what I call the enabling functions: legal, regulatory, intellectual property, IT and other business functions that are very likely to say "no" to your innovative idea. Perhaps the more important question is: when everyone is demanding innovation, why are these groups refusing it?
In my new book Relentless Innovation I wrote about the importance of the "enabling" functions to not simply respond to requests to support new ideas but to anticipate and even engage in the identification and development of new ideas. This would require IT to move from reacting to new innovation requests to become a leader in innovation across the board. IT would be a critical part of ANY innovation discussion, not just about new servers but focused on how to support new products and new services.
I don't mean to pick on IT - it's not as though they are the only ones who have to block, slow or stymie innovation in many firms. And it's not uniformly the case that IT is a barrier. In some firms, with visionary CIOs and CTOs, IT is on the forefront of innovation. But, more often, IT is the voice crying out "no" when innovation is proposed. But this isn't a screed against IT. No, this is a thoughtful, well articulated article about everything that you - and yes I am looking at you innovators - are doing wrong, forcing these enabling functions to say no.
Innovation in the "real" world
When someone in an organization gets the spark of a new idea, they often form a team to investigate the idea. This team examines market viability, financial opportunities and technical prowess. They decide that the idea has merit and they prototype and test the idea with customers. They receive excellent feedback and decide to promote the idea to senior management. Executives become excited about the possibilities for the idea and call a meeting of all the affected groups. At that point, six months or a year after the idea is first identified, the "enabling" functions become aware of the idea for the first time.
"Enabling" Functions
In every organization there are business functions that perform what I call the enabling functions. These are teams like legal, regulatory, compliance, information technology and other groups whose job it is to enable the product and service teams to accomplish their goals. These enabling functions provide two important capabilities. First, they ensure the product or service doesn't cause damage to clients or to the firm in the legal system, and second they ensure the product or service can be sustained in the marketplace. But these services and capabilities can't be delivered overnight. IT systems alone can take years to build, test and deploy. So your great idea that's been in development for six months may not have IT systems to support it for three more years.
But let's not pick on IT alone. If a legal team or regulatory team isn't aware of an idea and its impacts early in the discovery phase, you can and will spend time on ideas that aren't in compliance or would violate someone else's IP. Since these enabling functions have both a protective function and a supporting function, they have great weight at the end of the idea development process and the beginning of the commercialization process. And they can unintentionally stretch out the development of an idea and delay deployment for years.
Thin resources, long cycles
Most enabling functions are thinly staffed and have small budgets. Most IT budgets, for example, are focused on maintaining existing systems and have few dollars for building new systems. Even those dollars are often earmarked well in advance. If your product or service needs information technology in order to get to market, serve a customer or offer support (and which doesn't), then you need to align your ideas very early with your IT team. This doesn't mean that the IT team gets final say - it may be necessary to find external partners or rely on external platforms. But what it does mean is that your idea can't exist without the blessing of a range of enabling functions, and the worst thing you can do to an enabling function is surprise it with a new, valuable idea.
Further, it's not as though these enabling functions are sitting around waiting for a new idea to fall in their laps. They have full time jobs and responsibilities, full agendas with existing priorities. While your new idea seems very important to you, it is just one of a number of "top" priorities that already exist in the "to do" list. And many of those other priorities come with funding, with prior approval and have already been staffed.
Want to say yes, have to say no
Most of the people who run enabling functions, like regulatory, legal and IT, want to say yes to your ideas. In fact most of them want to be more innovative themselves. But, if they aren't aware of your idea early, if they aren't funded to support new ideas, if their resources are stripped back to only support maintenance, they have no choice but to say "no".
Changing the approach
If you hope to be a Relentless Innovator, you must engage your enabling functions early in the innovation process. Even then, even if they are more aware of ideas, that doesn't guaranteed their ability to respond as you'd wish. They will need more money for unanticipated projects and more people to respond to new requests. Further, they may need new, trusted partnerships to help them accomodate your requests. If those relationships are developed and exist as your requests emerge, you can quickly determine which approach is right for you. If those relationships don't exist, there is often too much work to focus on maintaining status quo and building new relationships under the gun.
In my new book Relentless Innovation I wrote about the importance of the "enabling" functions to not simply respond to requests to support new ideas but to anticipate and even engage in the identification and development of new ideas. This would require IT to move from reacting to new innovation requests to become a leader in innovation across the board. IT would be a critical part of ANY innovation discussion, not just about new servers but focused on how to support new products and new services.
I don't mean to pick on IT - it's not as though they are the only ones who have to block, slow or stymie innovation in many firms. And it's not uniformly the case that IT is a barrier. In some firms, with visionary CIOs and CTOs, IT is on the forefront of innovation. But, more often, IT is the voice crying out "no" when innovation is proposed. But this isn't a screed against IT. No, this is a thoughtful, well articulated article about everything that you - and yes I am looking at you innovators - are doing wrong, forcing these enabling functions to say no.
Innovation in the "real" world
When someone in an organization gets the spark of a new idea, they often form a team to investigate the idea. This team examines market viability, financial opportunities and technical prowess. They decide that the idea has merit and they prototype and test the idea with customers. They receive excellent feedback and decide to promote the idea to senior management. Executives become excited about the possibilities for the idea and call a meeting of all the affected groups. At that point, six months or a year after the idea is first identified, the "enabling" functions become aware of the idea for the first time.
"Enabling" Functions
In every organization there are business functions that perform what I call the enabling functions. These are teams like legal, regulatory, compliance, information technology and other groups whose job it is to enable the product and service teams to accomplish their goals. These enabling functions provide two important capabilities. First, they ensure the product or service doesn't cause damage to clients or to the firm in the legal system, and second they ensure the product or service can be sustained in the marketplace. But these services and capabilities can't be delivered overnight. IT systems alone can take years to build, test and deploy. So your great idea that's been in development for six months may not have IT systems to support it for three more years.
But let's not pick on IT alone. If a legal team or regulatory team isn't aware of an idea and its impacts early in the discovery phase, you can and will spend time on ideas that aren't in compliance or would violate someone else's IP. Since these enabling functions have both a protective function and a supporting function, they have great weight at the end of the idea development process and the beginning of the commercialization process. And they can unintentionally stretch out the development of an idea and delay deployment for years.
Thin resources, long cycles
Most enabling functions are thinly staffed and have small budgets. Most IT budgets, for example, are focused on maintaining existing systems and have few dollars for building new systems. Even those dollars are often earmarked well in advance. If your product or service needs information technology in order to get to market, serve a customer or offer support (and which doesn't), then you need to align your ideas very early with your IT team. This doesn't mean that the IT team gets final say - it may be necessary to find external partners or rely on external platforms. But what it does mean is that your idea can't exist without the blessing of a range of enabling functions, and the worst thing you can do to an enabling function is surprise it with a new, valuable idea.
Further, it's not as though these enabling functions are sitting around waiting for a new idea to fall in their laps. They have full time jobs and responsibilities, full agendas with existing priorities. While your new idea seems very important to you, it is just one of a number of "top" priorities that already exist in the "to do" list. And many of those other priorities come with funding, with prior approval and have already been staffed.
Want to say yes, have to say no
Most of the people who run enabling functions, like regulatory, legal and IT, want to say yes to your ideas. In fact most of them want to be more innovative themselves. But, if they aren't aware of your idea early, if they aren't funded to support new ideas, if their resources are stripped back to only support maintenance, they have no choice but to say "no".
Changing the approach
If you hope to be a Relentless Innovator, you must engage your enabling functions early in the innovation process. Even then, even if they are more aware of ideas, that doesn't guaranteed their ability to respond as you'd wish. They will need more money for unanticipated projects and more people to respond to new requests. Further, they may need new, trusted partnerships to help them accomodate your requests. If those relationships are developed and exist as your requests emerge, you can quickly determine which approach is right for you. If those relationships don't exist, there is often too much work to focus on maintaining status quo and building new relationships under the gun.
Voted 2nd best innovation blogger two years in a row!
0 Comments:
Post a Comment
<< Home