Responsive innovation - change management in a recession

Back in August I gave a short presentation to the JISC Innovation Group about the DevCSI project, introducing some ideas about possible future directions. The DevCSI project is a JISC-funded initiative designed to work directly with (software) developers in Higher Education through the general approach of encouraging them to establish a community or peers, sharing knowledge, experience, code etc. An aspect of this which has emerged during the first year of the project is the potential value in peer-training - where one developer trains a few of their peers. By supporting this kind of activity as an 'add-on' to larger events, we seem to have hit on a way to deliver extremely cost-effective training to (and, importantly, by) the sector's developers (we've done some work to calculate the financial value of this). DevCSI, then, provides a channel through which the sector, represented by JISC and UKOLN, can invest in its developers. In recent years, JISC has invested in some development programmes based around an approach labelled Rapid Innovation. Rapid Innovation, in this context, described an approach of investment in small, short, cheap development projects designed to 'scratch an itch'. There was more than an echo of the Agile Manifesto in this approach. The Rapid Innovation projects tended to show the following characteristics:

• they brought developers more to the fore
• they produced lighter, more frequent documentation
• they produced working code very early in the process
• they involved end-users directly, and throughout the project

The early work of DevCSI has been informed by this work - notably in the increased awareness of adoption of agile development methodologies. So why is this important? The radical changes currently being introduced to the economic and political landscape around higher education in the UK are forcing universities and colleges to re-examine themselves as 'businesses'. With the growing interest in commodified hardware and software and remote software as a service (SaaS) options for service delivery, HEIs need to examine how they can best exploit these opportunities. (The JISC's Flexible Service Delivery Programme has been established to help institutions in this). While HEIs will have differing levels and types of interest in what are being referred to as cloud services, they are generally going to be searching for efficiency-based savings. The value proposition of financial cost-reduction from using shared services is something which cannot be ignored by HEIs - but it seems to me that there are some things which need to be born in mind:

• the biggest saving in cloud-based services is to the supplier, not the customer (although the supplier will pass on some of this saving)
• this whole approach is not yet well understood - especially how SaaS sits with an 'enterprise' service oriented architecture (SOA) approach which is also of interest to some HEIs
• some services can be outsourced more easily, or to greater benefit, than others

In The role of the central IT Services organisation in a Web 2.0 world, Joe Nicholls and David I Harrison introduce the useful characterisation of services being either chore or core. Making use of SaaS is a form of outsourcing, and outsourcing is a tricky thing to get right. There are arguments for outsourcing those things you have to do but have no special interest in (e.g. HEIs frequently outsource their catering operation). In the ICT service context such services might include the various administration systems which all HEIs need to operate (e.g. finance). These we might call chore services. However, another reason for outsourcing is a lack of capacity or expertise to deliver a service internally - whether or not that is the preferred option. Services which are core to the HEI's business might fall into this category occasionally - even if this is not ideal. In a recession, with drastically reduced funding, HEIs might see more core services become unsustainable - or indeed need to reconsider what is core in the first place. Normally, business decisions of this sort are not so simply binary, and some complex judgement will need to be made. Inevitably, the growing opportunity for outsourcing ICT services will be appealing to many HEIs - whether those services are outsourced to generic or specialist commercial suppliers, or to HE-sector-based consortia such as the Kuali Foundation. But outsourcing can introduce hidden costs. A lessening of control is one obvious concern. But a more insidious risk introduced by an enthusiastic embracing of outsourcing services is a temptation to start to regard the maintenance of local development expertise as a luxury. After all, if we're going to outsource our ICT, why do we need to retain technical staff and, especially, developers. ICT is just a commodity, right? Well, no. I think it is a mistake to lose sight of the advantages that come from a local capacity to perform and deal with technical innovation. A local or 'in house' development capacity is a valuable resource in the normal run of things. In a recession, it is vital. The successful organisation will use a recession to examine its business and to change in order to be ready to fully exploit the economic recovery, when it comes. And large organisations are getting better at preparing themselves to be able to innovate internally or locally. Scott Anthony, who has worked with Clayton Christenson who coined the expression "disruptive innovation", lists some principles which inform an organisation's ability to engage in innovation:

• Put the customer, and their important, unsatisfied job-to-be-done at the center of the innovation equation
• Embrace the power of simplicity, convenience, and affordability
• Create organizational space for disruptive growth businesses
• Consider innovation levers beyond features and functions
• Become world class at testing, iterating and adjusting

(I'm not entirely enamoured of the 'disruptive innovation' label - as my colleague Brian Kelly pointed out at the recent CETIS Conference, the HEI sector is receiving plenty of 'disruption' right now from political forces - certainly enough to encourage innovation!) In Whither Innovation, Adam Cooper of CETIS asks: "Could we leave innovation to the commercial sector and buy it in?". Answering his own question, he quotes Cohen and Levinthal (1990) who introduce the term absorptive capacity, describing :

...a model of firm investment in research and development (R&D), in which R&D contributes to a firm’s absorptive capacity....

I see a direct parallel between outsourcing too much, and losing the absorptive capacity necessary to respond to change and to innovate to meet new challenges. In my talk to the JISC Innovation Group, I presented this diagram: This diagram tries to express the role of the local developer to act as an agent enabling and supporting change in an HEI. The developer deals with the remote, outsourced ICT system at a technical level, becoming one route through which the HEI ensures it gets the best possible value out of this arrangement. Remote services are, nowadays, guaranteed to offer some sort of application programming interface (API) which allows the more technically capable customer to tailor the service to their needs, rather than simply being obliged to use an undifferentiated, default user-interface for example. Local developers are increasingly networked with their peers in other HEIs (not least because of the efforts of the DevCSI project), so they become quite powerful in being able to exploit commonly used remote services through the free sharing of knowledge, technique and even code. And because local developers are, in some case, embracing a more agile approach to development, they become the conduit through which the end-user expresses their needs to make the remote, shared service better fit their local, idiosyncratic needs. Developers can become surprisingly aware of 'business' processes and information flows through an HEI, as they have to deal with them at several levels (I wrote about experiences of this sort in a previous post, SOA and reusable knowledge). I see an opportunity for the DevCSI project to focus its efforts on this aspect of change within our HEIs. Change management is going to be crucial for HEIs as they redefine what is core and what is chore, as they decide what they can do best, and what can be best done for them by others. They are going to need a capable, knowledgeable and above all agile capacity to innovate to meet new business challenges and a changed ICT environment. I've taken to using the label responsive innovation to describe the act of dealing with or instigating technical change in a manner which advances the core mission of the institution. Developers are not the only part of the solution, but they are a vital part. Not only do HEIs need to hang on to their best developers, they need to invest in them, if they are to manage change and not be managed by the changes being imposed on them. Developers are core.