For many years IT departments struggled with the idea that the way in which they delivered services should be based around delivering to the needs of their business. Technology projects would be self-serving, and as a result often fail to deliver anything of value.
In the 1990s we started to see the rise of business case-led approaches to how technology should be procured, built and used. This seemed to align projects more successfully to business outcomes, but with an over-reliance on optimistic planning and budgeting processes often the business case could run away from reality. Again, the demonstrable value delivered from such projects of work was at best a bit hazy.
With the rise of the consumer internet in the 2000s, and with the shift in devices from PCs to Phones that has been one of the dominant features of the last decade, the shift in approach has been from a focus on business needs to those of users – whether end customers of a business, or the people working within a business. This is an approach that is still nascent in many organisations. The theory is that if you build something that meets the needs of the user, in turn it will support the needs of the business.
When it comes to the use of technology as a sustaining innovation this is probably a good approach (although neither completely losing sight of the business needs, or developing something that puts unsustainable maintenance into the laps of the technology teams are good ideas). But sustaining innovations, incremental improvements to the way in which things work at the moment, will only take an organisation so far. To deliver significant step change, somehow user, business and IT needs all need to be inspired by the things that technology might make possible. Technology-led change.
How to do this? Well, that’s the million dollar question. But from experience over the past 20 years, my hunch is that it comes bottom-up. In fact, there’s probably a stack of it going on in most organisations today with the “shadow” use of internet-based technologies by small groups of people in businesses doing things “on the side”.
Too often this type of activity is frowned upon, if not actually strongly discouraged. But if you don’t allow people to experiment and play with technology in the workplace, what message does that send?
I can think of at least three messages: we don’t trust our people, we don’t want them to come up with ideas for how they can work better, and we think we (the organisation) knows best. If you want to ossify, then that’s a good strategy.
But if not then allowing the experimentation to flourish, and learning how to learn from that play need to be fostered not controlled.
mmitII 