When talking about change there are always at least two points of view: the ones performing the change and the ones affected by the change. The ones performing the change are usually convinced that the change is necessary and beneficial for all. The ones affected by the change often don't view things from the same perspective. This leads to resistance to change and many problems (costs, delays, frictions, pressure, stress, ...).
Change is one of the biggest communication and management issues companies come across. And it happens often and usually not too well. Many enterprise activities require change to be handled (PLM, Six Sigma, TQM, ERP, Lean, ...) but in reality few actually give pertinent techniques or advice on how to do so. Here you'll find an original technique for managing change which when applied can make change an easy process rather than a tedious one.
What we call spontaneous change is a method for inducing change in an organisation without suffering any resistance. The magic is in the word 'inducing', because it doesn't say who 'induces'. The idea is to make change spontaneous, that is make the people affected by the change be the ones who create the change.
This is possible by providing the motivations and tools to create the change. Instead of imposing change on people rather provide them the context to want it and ask for it.
But, 'providing the context' itself requires changing something (the context). So, how can this be resolved?
The fact is that a very little change in context can generate (via this method) very big change on people. So, spontaneous change does in fact require some initial contextual change to be performed (and imposed) but this will be much better accepted because it will be very mild (compared to the real wanted change, which will become spontaneous) and less focused usually (avoiding crystallising specific aspects). In fact, the initial contextual change can clearly be geared towards popularity, because it isn't itself the finality, so it can dismiss all controversial elements and keep only the consensual.
Change in Information Technology
This method gives very good results for example for deploying new Information Systems (for example an ERP) to users. One of the biggest causes of failure with IS is simply that the users don't accept the change which is imposed on them, thus finding all the possible reasons for not using the IS which finally appears to be an enormous waste.
Why does this happen? Our experience is that usually large ISs (specialy ERPs) require a too bigger step for people to accept it, the new IS simply changes their ways too much in one move. The usual method used for ERP deployment doesn't solve this as instead of making change progressive at individual scale it makes it progressive at organisational scale. Specifically, the usual process is to deploy the system progressively across the organisation by starting typically by finance, then moving to marketing, then sales and so on. Although this may look good on paper, in fact it doesn't handle the real problem which is individual change. A better solution is to deploy the IS progressively on an individual level and globally at the organisation level.
What this requires though is to be able to deploy progressively at the individual level an IS which will at first basically change as little as possible, if possible nothing (people do the same as before, but, for example, instead of filling in a paper formulary, they fill in a electronic one, but with the same fields, no 'clever/innovative' helpers yet). Leave the people use this then Magical Change will happen: people will start proposing improvements themselves, that is they are asking for change. Usually, their requests will be pertinent because they are the people who know their job and should be willing to improve (motivational incentives can be used), and once into the 'change process' they will easier accept ideas from others too (who can orient change to what they finally want). In fact, at this point it is likely that the people who initially wanted the change will find themselves trying to slow down and moderate peoples' change requests.
However promising this seems, it in fact isn't too popular for now because ERP vendor's sell products which aren't suited for this method because they include complex functionality which imposes change on the individuals brutally, thus only leaving them the 'department by department' approach. Applying this requires a more adapted approach to ISs which allows a more progressive introduction on the individual level.