I’ve been giving some thought, and just a little reading, to the concept of User Innovation and its impact on IT. Because we are talking about User Innovation my primary area of interest is with the End User devices and the services that they are provided with.
To start with it’s worth putting some form of definition around the phrase User Innovation. I’m primarily talking here about the phenomena researched by Eric von Hippel and documented in The Source of Innovation and Democratizing Innovation.
Perhaps the best way of defining it is to describe a personal experience. I use Flickr as a photo sharing site, when I first started using the site I noticed that there wasn’t a group for photographs of Lancashire, where I live. So I created one. Having created one I invited others I know to join it. Not long after I’d created the group Stu notices that the group has a strange URL and thinks that it would be great if it had a simple URL. What’s more Stu did a bit of research, worked out how to do it and gave me the instructions. So now Flickr has a Lancashire group with a nice simple URL (http://www.flickr.com/groups/lancashire/) where people share pictures almost every day.
There are two innovations in this example, the creation of the group and the change of its URL. Both of these innovations where undertaken by a User of the service, not by the Manufacturer of the service. I wasn’t 100% happy with the service as it was delivered to me by the Manufacturer, so I modified it. Fortunately Flickr has been built to encourage that kind of innovation, but more than that, the modification I made was immediately available to the whole community.
The alternative to User Innovation is Manufacturer Innovation. In Manufacturer Innovation it’s the person who is creating something to sell that undertakes the innovation. Manufacturer Innovation normally to follows the design, build, test, deploy process, with the requirements for the design phase coming from within the Manufacturer.
I have a lot of experience as a Manufacturer of End User Services (what used to be called Desktop Services). I (We) design a service and sell it to the people who are going to Use the service changes to the design are driven by the internal development process.
For years there has been one primary driver for the development of these services – cost. This has included the cost of support as well as the cost of acquisition.
If you want to reduce the cost of acquisition then you need to make the delivery of a service highly automated and to automate something you need repeatability. If you want repeatability then you need uniformity. Delivering 1000 PC all the same is cheaper than delivering 1000 PC that are all different.
Capping the ongoing costs requires the perpetuation of that uniformity, but more than that, it requires simplicity. If you are going to maintain simplicity you need control.
Uniformity and control might cap costs, but they also stifle User Innovation. The need to innovate is strong, though, and Users of the service innovate anyway. They innovate outside the boundaries of the control whether that’s through Internet delivered services, or by utilising equipment outside the control of the standardised service (like the PC at home) or by finding loophole in the control.
So the costs still exist, they have just been moved, and probably increased by people working around the system.
On the flip-side of this debate is the need to protect User Innovators from themselves, but more about that another time.