How to cope with change: An alternative approach

CHANGE...

A lot of people are involved in change: Every project is a change, and every change should be a project. In project management, one is used to document risks of the project and think about how to mitigate those risks. Sometimes, mitigating the risks can be costly. But on the other hand, having the risks and the possibility that something goes wrong may cost more.

A risk that is often forgotten in projects (and thus also in processes of change) is the one of 'changing people's mind'. Letting a human being start working (or even thinking) differently is a great challenge.

In other words, there is a technological barrier and a mental barrier to any project or change process. Both generate their own set of risks to be taken into account. In many cases the mental barrier is forgotten or at least underestimated.

A technique that is widely adopted in situations like this is 'chunking' the technology: go step-by-step. Start small, but gradually extend the scope of the change. Doing this on a technical level usually also impacts the mental barrier.

Recently, I was talking to a project manager for a technology company involved in the 'people change' process in relation to nanotechnology and its applications in biomedicine. He told me that the mental aspect of the whole project, the fact that little things enter our body, or even remain there for years, is to a large extend not yet common ground in our society. This is a considerable risk for the development of new applications of nanotechnology.

In order to mitigate this risk, the project manager told me they sometimes developed a completely different product first (and freezed the other project) because this new product was easier 'to sell'. So basically, you develop something in parallel in order for people to feel comfortable with this change because it will make future changes easier.

"But this costs a lot of money!" Yes, obviously, but so does developing a product that has a high risk of not being adopted because the mental leap is too big.

Did you encounter situations where the parallel development approach might have been successful? Please share it with us in the comments.