Internal IT innovation is all about converting ideas, those specifically supported by new technologies, into business value. These innovations often focus on needs such as improved internal processes or alternative and creative ways to support market activities. Four years into leading PwC’s IT innovation efforts, I’ve certainly observed enough of what works and what creates challenge to write a book on the subject.  For this blog posting I’m going to briefly discuss an element of what I’ve experienced. It’s what I will call the 3 tensions of internal IT innovation.

1.    Technology is inherently innovative, so why have an IT innovation team at all?

When I formed our IT innovation team, this was the first question that needed to be answered. It’s a core tension: IT already innovates so don’t create confusion or competition by introducing a separate innovation team. It’s true that by default, deploying technology in an organization usually results in innovation. The existence of that new technology generally brings new capabilities and as a result new value is derived.  However, there is an important characteristic of IT innovation that makes it unique. It is the quality of embarking on an effort when there is a significant chance of failure. Normal, business-dependent projects never kick-off with this premise. It would be unacceptable.  Since IT innovation projects often deal with speculated outcomes and unproven, immature technologies, most of the time you’re spending money with the knowledge that the purpose of the effort has more value beyond successful deployment. If you can get this to work within your existing IT structure, then you’re more progressive than most organizations. In my experience, the separation of the team is essential to strike the right tension. The takeaway here is to get your leadership and participating teams to understand and accept the premise of this tension from the outset.

2.    IT innovation projects fail more often than they succeed creating a negative perception of value.

The previous tension provides the necessary background to this second tension.  Simply stated, if we accept that the value of IT innovation often transcends successful deployment, then we must manage the incorrect assumption that failure is bad. If those writing the checks only measure IT innovation project success by deployment success, then a negative, ultimately destructive, tension will exist.  To strike the right positive tension, I believe IT innovation success must be measured in ways not normally associated with technology projects. By its very nature, IT innovation has many unknown characteristics, for example: will it even work, will people ever use it? By engaging in an IT innovation project we hope to answer these types of questions regardless of the desired outcome. These insights can create competitive advantage and should be used to inform decision-makers and feed into other projects.  To get this tension right, you have to proceed with project success in mind, but balance it with communicating the value of the spin-off insights that result from failure.

3.    Essential IT projects to run the business almost always trump internal IT innovation projects.

There is likely no organization that exists where the available IT supply exceeds the demand. More likely, every IT organization deals with a magnitude more of user needs than they could every meet.  This is why effective IT project governance that results in prioritization is so important. The most valuable projects are given preference which often results in the more discretionary and apt-for-failure IT innovation not meeting the priority list. To address essential business needs while also spending on speculative IT innovation is probably one of the hardest of the tensions to reconcile.  In my experience I’ve seen at least two prominent approaches. The most common is to have a separate budget for IT innovation. This way, they get to operate without the burden of producing elaborate return-on-investment projections and competing with projects that run the business. The challenge is, of course, that every group wants its own dedicated budget and singling out the IT innovation team can cause an organizational backlash that relegates the IT innovation team to the periphery of the action. On the other hand, the benefits if you can make it work are abundantly obvious.  The second approach is to have the IT innovation project proposals go through the standard IT projects governance process.  The premise is that IT innovation project proposals should be subjected to the same evaluation and diligence as every other project and move forward based on relative value. Where do I stand on this?  While a brief response can’t address the deeper discussion here, I believe that you need both approaches but with specific demarcation.  IT innovation teams should have a budget to just enough to cover the analysis and feasibility of an effort. Often this is sufficient to glean the insights that make more work unnecessary. However, if money is needed to build a prototype or to run a pilot, then I think it’s reasonable to run the proposal through the IT governance process.  A great internal IT innovation project proposal should sell itself on its merit.  Positive tension in this instance is getting decision makers to carefully balance necessity with speculation.

Let’s be clear, understanding and addressing these three tensions in the right manner will largely depend on your organization. But I’m confident you have had to or will have to address some manner of them. While certainly not an exhaustive list, at least if you can get these three right early on, you have a good foundation for future success.

What has been your experience with these three tensions?