|Revision 1.0||6 June 1999|
We in the software field push change. Ours is a young science, and we are using different tools and techniques constantly in an endeavor to improve how and what we do. The improvement applies to both strong and weak organizations. Weak organizations obviously need to improve to avoid project failures. Strong organizations need to be stronger in a competitive market.
People don't like change. Change means moving from the familiar to the unfamiliar, and unfamiliar means uncomfortable. We are afraid of anything different. I didn't like it when my wife suggested painting the kitchen cabinets.
The constant change and resistance to change creates an obvious and frequent conflict in our field. A consequence is that wonderful ideas are not used. We languish in the same old inefficiencies and make the same old mistakes again and again.
Overcoming the resistance to change is one of the biggest challenges facing us today. Change, though frightening at many levels, is necessary in an ever changing field. We, project managers, consultants, and writers, must find ways to work through this.
One approach to this problem is to give people time to change. Time allows us to become familiar with the unfamiliar. Being familiar moves us from being uncomfortable to comfortable. It allows us to give an idea a second thought. Maybe painting the kitchen cabinets might be ok.
I've used a couple of strategies in giving people time (I've also had these used on me successfully). One strategy is to chat with people informally days or weeks before formally suggesting a change. The informal chats are far less threatening. The suggester talks around an issue ("this kitchen looks old"), solicits ideas ("what do you think we can do in this kitchen"), and mentions several ideas ("I've seen pictures of etched glass cabinet doors and other pictures of painted cabinets"). The suggester doesn't push any one idea and doesn't try to bring the discussion to a conclusion yet. Again sometimes I do suggesting and other times people have done it to me.
Another strategy is to spread a suggestive meeting over two days. This is less effective, but useful when days and weeks are not available. I used this recently with a group on the west coast. I visited at 1 PM on the first day. We went through my suggestions for a couple of hours, and I left them with some materials and ideas about 3 PM. We met again around 10 the next morning. This gave them a couple hours in the afternoon, the entire evening, and a couple more hours the second morning. That time allowed them to chat with their own people, check on a few items, and think about the suggestions.
They went along with (most) of my ideas. Had I come in with a one-day visit, I would have returned home with no conclusion. They would have asked for more time to check on things and think about it.
Both of these strategies require planning. I need to understand the necessary change, the identity of the key decision makers, and when it should happen. I must allow time for people to become familiar with the change.
Some may consider this a distasteful political game. Be careful as it may be seen as such. If that happens, the change is sunk.
This is an effective means of communication. It allows an idea for change to get into the head of the other person. It allows the other person to give it a second thought.
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He helps people manage software projects, i.e. he tries to convince people to change. He has written "The Software Project Manager's Handbook, Principles that Work at Work," IEEE Computer Society, 1998. He has a Ph.D. in electrical and computer engineering from Louisiana State University. He can be reach at firstname.lastname@example.org.