I read your blog entry and all you say there about social networking is, for me (my perception, hehe) very relevant to perception management too. I’ll try to cover some of the issues you raise in one of my next blog entries. And I’ll get to read your blog in the future. Thanks a lot !

the issue you raise of the «PrimaryStakeholder/Check-Signer/Owner who doesn’t WANT you to work with the end-users» is a very important one and, unfortunately, one that many project managers face.

I also face it, even in project-oriented processes implementation projects, where it is not only a technical solution you are trying to deploy but, mainly, a major cultural shift. I am always appalled at this type of behavior from the Project Owner/Sponsor, but, once persuasion has failed to change this position at the beginning of a project, I just have to accept that this person is at this point in his/her personal development and that further experiences of personal failure to impose changes (and personal recognition that it was this end-user-excluding behavior that caused the failure…and the humility to accept accountability) are the only way this person will evolve. And ultimately, he/she will have a better understanding of how end-users (intelligent, resourceful «collaborators» for the Prime Stakeholder organization) can make a real difference if you try to communicate with them instead of to control them.

This is a sad situation and, unfortunately, I have not much more to propose than to insist that end users be included in the project early when you can…and then, through frequent return-on-experience/lessons-learned sessions with the project Owner/Sponsor AND the project team during the execution of the project, to always come back with the need to include end-users to accelerate benefits realization afterwards. I am not sure that asking this person to read the Chaos Report would make a big difference, since behavioral changes are not accomplished though only thinking, but also through feeling. Attending a workshop on Emotional Intelligence would have a better chance to give results. hehe

A thing that sometimes works for me is «direct empathy». This is based on research on the «perception of risk» and the subsequent trust in others during difficult situations (like changing a work environment, hehe). Always talking to the Owner/Sponsor in terms of benefits to gain or benefits to lose for him/her (using real empathy towards the Owner/Sponsor main concerns) is a must and should be the preferred approach over talking about detriments to users (showing empathy to the end-users when you deal with the Owner/Sponsor is not a winning strategy).

If this does not work, nothing will since it indicates that the organizational climate is so bad that the Owner/Sponsor is ready to forfeit his/her own project benefits to prove a point and prefers to exert control over others for the sake of it instead of relying on others as partners in his/her personal success. The paradigm shift required from this person is too strong; this shift can only be accomplished because of a very significant disastrous event or simply because this person is replaced by someone who believes in collaboration and in the value and capability of the project end-users.

So, keep going Joel. I believe you do a very good job at what you do. You have the right mindset. But you cannot change others if they are not willing to change themselves. And I am sure that ultimately, because of your sensitivity to end-users, you do you best for them.

Most of my projects are small infrastructure implementations for customers, so the primary stakeholder is often also the check-signer and the owner of the company. As such, the projects I implement are often tools that the owners use to force change upon their employees. I know that end-user involvement is a key factor to success, but sometimes the PrimaryStakeholder/Check-Signer/Owner doesn’t WANT me to work with the end-users, because he/she wants to push organizational change moreso than create a business solution that the end-users are enthusiastic about. Usually this results in a successful implementation, but sometimes users don’t bite and the project is a technical success but an organizational failure.

Do any readers have any brilliant thoughts about how to deal with this?