When I was in my mid-twenties I took a visitor from the Ukraine to dinner. She was in town to attend a wedding and I wanted to shown her my city. She spoke several European languages, none of which was English. I spoke English and several other languages, but my list included Fortran, Pascal, COBOL, and C. In theory, we should have had a serious communications issue. But we didn't. I explained most of the menu by mimicking the sounds of the various farms animals on the menu (much to the amusement of everyone at the surrounding tables) and we both ended up enjoying the evening.
Partially based on this experience I have always been suspicious about communications issues. I never cease to be amazed at how often IT folks point the finger of blame at communications skills. Repeatedly I hear "everything just boils down to communications" or "if we could just communicate better everything would be okay" or "all our problems could be solved by better communications." I don't agree. I would go so far as to say that there is no such thing as a communications issue. Faulty communications are inevitably an indication of a deeper issue. Communications issues are only symptoms of real problems. If you solve the issue at the communications layer, you are not solving the real problem. You need to dig deeper if want to create a sustainable fix.
For example, I once replaced a CIO who failed with an ERP implementation. Folks claimed she failed because she did not communicate in an accurate fashion. She had oversold the benefits and undersold the costs, so her communication had twisted expectations beyond the realm of reality. This observation may have been true on the surface, but why did she feel the need to distort the messages? She clearly felt obliged to make exaggerated claims about how the system would improve the organization at bargain basement prices.
So why did she do it? She was right that the organization needed an ERP system and she was right that the benefits are hard to explain. Try telling a senior board member that an integrated database will improve the strategic mission of the enterprise. But instead of taking the time to educate folks on the issues, she tried to sway them with promises that could not be kept. In the short term she was able to sell them on the concept and got buy-in to the project. In the long-term she couldn't keep her promises and paid the price of not being realistic.
This approach reflects a lack of patience for explaining the real reasons to undertake a significant project. Take the time to understand the issues yourself. Think in terms of your stakeholders. Understand their needs, their fears, and their language. Instead of talking about "integrated databases", call it a "single source of the truth." Spend the time educating and informing before selling. You may be surprised by what you find. Maybe your organization doesn't really need the new system after all - or maybe it needs the system more than you realized. But this isn't about communications. This is about taking the time to understand the fundamental issues before moving forward. Look before you leap. Think before you communicate.
Whenever I hear IT staff complain about a communications failure I like to probe into the underlying motivation. Sometimes "communications failure" really means, "I don't want to communicate" because "I'm afraid to let them know what's really going on." If your staff are afraid to pass on an honest message, then it may be due to a lack of skills, inappropriate control processes, or a repressive departmental culture. And that's your fault, not theirs. Let's look at each of these three issues separately.
When I talk about lack of skills, I don't mean the basic ability to talk and write. Let's assume that you have hired folks who were sufficiently educated to earnestly function in your IT shop. But what they might not have are the skills to face a problem in a direct manner. You need to teach them how to frame a problem and give it context. IT staff need to avoid the "the sky is falling" approach. Chicken Little will only panic your customers. Your staff need to be coached on explaining the issue in plain language without emotion and with potential recommendations. Issues are lonely creatures - make sure they are always accompanied by a solution.
Once your staff have the skills to give the problem the appropriate context you need to implement non-bureaucratic control processes. Give them the opportunity to explain problems. For example, your projects will inevitably go through changes during their lifecycle. If modifications are inevitable, so is the need to explain why you need to make the change. Build mechanisms for escalating changes into your project management methodology. Ensure project steering committees are trained to expect these shifts in plans. Too often "poor communications" are blamed for what in reality are poor processes.
No matter how much context and process you provide, if your culture does not encourage open and honest discussion of issues, they will remain veiled behind the hazy cloud of "poor communications." Shooting the messenger doesn't change the truth; it only hides the truth. That's when communications skills get blamed. But even the best communications in the world are not going to change a repressive culture. You need to nurture the ability to say, "I made a mistake." Mistakes are tolerated and learning outcomes are encouraged.
These are just three examples of when communications takes the blame for more fundamental problems. Sometimes a communications breakdown is based on an emotional fear of change. Change is like a death. The old way has died, and the new way is an unknown and unfamiliar place. Fear of change is irrational, but real. But it is not a communications failure. If you simply address the communications issues you will never fix the real change management issues. Address the change head-on; don't wallow in the black hole of superficial communications-driven fear and loathing.
I have implemented major change initiatives where the communications are quite easy and natural if you have done all the other hard work. This hard work includes really understanding your stakeholders. Spend time getting to know what makes them tick. Engage them in a meaningful way in the decision-making process. Create an education process for you and them. The more you both learn about each other at the beginning if an IT initiative, the easier it is to talk frankly and openly when issues arise. When someone blames a "communications failure" someone probably hasn't done the hard work.
There is an interesting follow-up to my dinner with the visitor from the Ukraine. I attended the wedding with my dinner companion the next day. At the reception a couple came up to us and revealed they were in the same restaurant as us the night before. We were a little embarrassed until they said they made their dinner choice based on our mimicking of animals from the menu. They chose the Chicken Kiev.
~
No comments:
Post a Comment