Getting to the point of change 2

At the end of the day people are people, and its not really in the remit of a technologist or consultant to try and change the human state. Even so a basic understanding of how we all tick should be at the core of any business change activity.  Like it or not successful leaders and advisors do understand how folk tick, its why they are successful. But that does not mean that they are neccessarily empathetic or caring - it means that they know how to get things done and how to get people to change ingrained habits and processes. Enterprise technology projects are seldom led by strong leaders, rather they are led by folk with a good understanding of the technology, the company or both.
As such major change projects that would have otherwise had input from HR professionals or outside specialist consultancies elsewhere in the firm, are classified as IT projects and don't get that input.

If business change is involved, and it almost always is in Enterprise Software and Services situations, then you need to start planning the change process long before you get involved in selecting technology. You need a no holds barred discussion at a high level about where things are going, and most importantly the risks involved in the change and what could potentially go wrong.

In my experience IT projects are seldom open and honest about what changes the firm is hoping to make with the new technology, either with themselves or with others. Project failure, despite it being so common is simply not considered an option. This whole area is something to explored at another time. But the issues of openness in general is relevant to this particular discussion.

For example, in a few cases I have seen projects essentially run 'secretly' with the the new product or service being delivered as a fete accompli (or so they think). The other common approach is the co-operative approach, where management tries and listens to everyones views/needs and to accommodate those views/needs. Neither approach works.

In the former approach (withholding information about the full or true nature of the project) you almost guarantee significant and often very successful resistance at roll out. In the latter you run a high risk of ultimately losing control of your destiny. The truth is you meet everyones needs, nor should you try.

But maybe these two approaches, and all those in between mask the true path to success. To be clear honesty is as always the best policy, and organization both big and small are terrible at keeping secrets. Either the truth will out at an inopportune moment - or just as bad people will simply put their own (usually negative) interpretation of events onto the situation. If perception really is reality, then you have serious issues across the board. Honesty, even if its brutal (quite different to uncaring or malicious) is essential.  For example, telling folks up front that the purpose of this IT project is to provide support for a headcount and cost reduction and will likely involve the restructuring of some business units - isn't going to go down well, but at least its the truth and people can work with that. Either to find timely new employment elsewhere to support themselves and their families, or to find a new role and adventure in the changed organization. But honesty and clarity, though important isn't enough. Folk have to want to change, they have to be excited about the change, they have to be uncomfortable about the status quo. They also have to embrace the risk and be committed to making the change - accepting that all will not go smoothly, there will bumps in the road ahead - but they have the drive and vision to navigate a road through.

To be continued (maybe)