The number of books and articles that talk about talking innovation from the famed designer’s clay models to the world all around, is not to sneeze at. More and more firms have appointed Chief Innovation Officers in the last decade, recognizing innovation first as a game changer and later as the competition balancer. Innovation experts have been regularly hired to conduct seminars and full-fledged workshops for startups, mid-sized companies and big players all alike. Gurus have gone so far ahead to even say that innovation is a necessity for survival in any game, be it product or service.

But can innovation really be offered as a service? The world of IT is renowned for its chaos and difficulty of aligning projects into well-defined processes: there is always some scope for something to go wrong, some integration point to be missed, some vulnerability that does creep in and other factors that lay mockingly outside structure and predictability. Pundits do argue that the very nature of such a business renders the delivery of innovation services a daydreamer’s sphinx.

Innovation as a service 198x300 Innovation: Service or Process?

What if it is not?

Innovation may not need an introduction today. For a good textbook definition, ping your CIO or ring up your user experience vendor. Problem Solved. The actual application of the principles of it, broadly observation, ideation and prototyping take time and years of controlled venting of creative energy. It’s like having your foot on the accelerator: no pedal, no speed, and at full throttle you may lose control and become wall graffiti. The control over the accelerator in the analogy is actually the filter of the generated ideas. Shooting down ideas is a cardinal sin in the innovation bible. Giving a green light to each one of them however won’t leave the electricity on for more green lights ever.

But how does this relate with Innovation being a service or not?

Innovation, with all its recognized peccadilloes, is a discipline today with recognized peccadilloes. Those recognitions are what have put innovation in a consistent and commendably predictable framework. That framework once taught and adapted starts bubbling up in the organization culture that seeks to solve its own and its clients’ problems utilizing insights gained from trained observations. By now it must be clear that there are two levels of complexity to deal with. The first is the complexity and the creative side that innovation brings in. The second is the well persisting chaos in the IT world. Let’s call the two- iC and iTC. My argument is that Innovation Complexity (iC) is already dealt with thanks to the tremendous body of knowledge that today makes iC “weaponizable”. The second level of complexity is iTC, to control and mitigate the risks of which, we have various IT processes in place.

For a normal output with innovation we have,

Output (O) = Innovation (I) + IT + Cfunction ( iC, iTC )

The Cfunction here is a control function that is the key to make innovation in IT predictable, scalable and ultimately a deployable service! What does the Cfunction do? It not only inhibits but also it catalyses the complexities. For the creative energy to flow, for the disruptive ideas to come out and change the world, some (not all but some) chaos is useful. Some of the little streaks of unpredictable nights of coding, those integration problems that the projects runs into, the client’s unrelenting and new demand to make everything run everywhere, are the complexities that offer opportunities to truly create disruptive innovations.

The Cfunction is called so because of another reason. It is the C-level folks that truly control this Cfunction. They decide how strictly things are regulated and how to keep some room open for the innovators to get their sparks. For example, in SCRUM meetings, a special innovation couple of minutes may be added with the open question, “Anyone have any good disruptive ideas?” As naïve as it sounds, just a little tweak like this can start getting people in the Innovation Mode. To control the iC, we can have repeated brainstorming ‘ideation’ meetings like SCRUM. These are just ideas I am thinking out loud. The C-level people controlling the parameters can come up with some great manoeuvers within the allowed frameworks.

Now that we see that Innovation and IT parameters can be controlled to generate predictable and repeatable processes for innovative output, the only next step is to identify the roles people are slipping into, in the teams. It would be observed that some have better grip on processes and are better at doing things by the book. Then of course, the other end of the spectrum has the classic misfits and rebels who get those sparks. Somewhere in the middle lie people who are creative and yet who understand the business constraints and are ideally positioned at sorting and sifting through the ideas. Once the innovation processes as discussed before are run again and again, the patterns of the team seem etched more clearly on the woodwork. Again, a C-level or skilled HR officer is best poised to identify such patterns.

After the process maturity and team selection, the final deployment of this service remains. Innovation as a service must always keep the customer pivoted at the center of the unfolding of the magic. The team, now composed of the process experts and executers, the crazy thinkers and the business literate creators need the final piece of the jigsaw. The perfect bridge between the client and the team. Some skilled coordinator who is well versed with the parameters of IT and Innovation would fit very well in this role. The best part of having a team like this is that, it can slowly evolve into a technology-agnostic, free-thinking and pluggable entity that can attach itself to any project  and bring about disruptive change and then go on to the next project.

This is an Innovation Unit, a refined, powerful and experienced roster that renders Innovation truly as a buyable service.

About the Author:

 Innovation: Service or Process?
Abhishek Mishra works as a Solution Architect at e-Zest in the Presales division. He proposes technology stacks best suited to client requirements. As a part of the development team in the TABit project, he is responsible for advancing the framework-level changes in the project. Having recently begun his journey with e-Zest, Abhishek loves to share his knowledge thorough his blogs. Other than his passion for learning new technologies, hobbies like playing a string or two on the guitar and writing fictionalized accounts of real-life events fills his leisure time.

Recommended article: Chomsky: We Are All – Fill in the Blank.
This entry passed through the Full-Text RSS service – if this is your content and you’re reading it on someone else’s site, please read the FAQ at

e-Zest | India | USA | UK | Germany | Europe