Fear and Loathing in IT Communications

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.

~

Are Students Customers or Products?

Are students customers or products in an higher education institution?

The answer to the question is forced upon higher education institutions by the very nature of the information systems they implement. There are two types of systems in a higher education environment. Some information systems treat students like products of the institution and other systems treat students like customers of the institution.

ERP systems like Banner, Kuali, and PeopleSoft are designed to maximize efficiency. By simple virtue of the need to process large volumes of students in registration or accounts payable, the student becomes a product. They enter into a system for processing like unfinished goods. The administration module begins processing the large volume of raw material (applicants). The registration system and associated systems like the degree audit system help track the work-in-process inventory (students). Eventually they become finished goods to be delivered by the convocation system (graduates).

Learning management systems such as Moodle and BlackBoard are designed to enhance learning outcomes and improve the educational experience. The LMS is designed to help students learn the course material. A well-designed LMS environment provides consistency throughout the student's lifecycle at the institution. They are designed to optimize the learning experience with little consideration given to maximizing efficiency. Similarly, campus services such as wireless are architected to improve the student experience through ubiquitous service and gobs of bandwidth. These types of systems are intended to treat students as customers receiving a service from the institution.

The student help desk is a transaction-processing environment. Clear response and escalation processes are defined to maximize the customer experience. Effectiveness of response, and customer satisfaction take priority over efficiency. High touch and human contact create a positive student experience that will improve student retention. Conversely, billing students for tuition is a production process. It is a process that demands financial rigour and productive use of system resources. The entire billing system is designed to be as efficient as possible.

To be a truly effective CIO in a world where students are sometimes customers and sometimes products is what makes the job interesting. The real opportunity for a CIO in the higher education world is to understand when to see students as products in certain circumstances, and when to focus on students as customers in other scenarios. This wonderful opportunity forces CIOs to deliver process efficiency and learning effectiveness concurrently to the same group of people. The best CIOs are good at both skills sets and know exactly when to apply the right approach.

One more wrinkle to make it more interesting. Are faculty and staff customers of the IT organization? I suggest that IT needs to treat faculty and staff in a more thoughtful manner than just customers. Like consulting firms, IT should consider faculty and staff to be clients. A client relationship suggests a more nurturing and enduring relationship based on more complex relationship than straightforward customer transactions. WalMart has customers. McKinsey has clients. Which way do you think your faculty and staff would like to be treated?

~

The View from IT Mountain

For the first time in my life, I went mountain biking. It was exhilarating, frightening, demanding, and fun. Most of all, it provided a unique view. After a long climb to the top of the mountain we came to the edge of the first trail. I also came to the edge of a clearing where I could see everything - the adjoining mountains, the community where I live, and the remarkable path to the top of a small mountain.


While I paused to catch my breath (which was a good long time), I had a chance to think about the unique view that IT has in any organization.  Much like being at the top of a mountain, IT gets to see everything in an organization: the hills, the valleys, and the paths connecting key centres. No other group in an organization has such breadth. Marketing, finance, manufacturing, and HR have incredibly deep understanding of their own valleys. They might also have a wonderful knowledge of how their department connects with some neighbouring organizations in the adjacent valleys. But they do not see the whole connected picture.

Can anyone connect all the dots?

A truly successful IT organization can see the whole picture. Its job is to work with all facets of the organization to build integrated information flows. The role of IT puts the department in a unique position. A successful IT service transcends organizational boundaries. IT delivers service horizontally across the entire organization enabling it to see all the valleys, all the connections, all barriers, and all the opportunities.

How can organizations leverage the broad IT perspective?

To start with,  IT departments need to view themselves as holistic and systemic process improvement groups. They are not just technologists, but broad integrators who bring together people, process, projects, and technology from across many disparate units to deliver unified systemic change. If an IT organization builds trusted relationships with all its partners, it can leverage  its unique perspective through these relations into a powerful wellspring of change for everyone in the organization.

Does IT need help walking to the top of the mountain?

To succeed, organizations cannot bury the IT department at a low level in the organization. Reporting needs to be at the most senior levels in the organization. High level reporting responsibility enables IT to move customer initiatives from a technology focus to a business focus. IT applies the force of broad horizontal connectivity to topple the vertical silos of political dysfunction.

Is simply changing structure enough?

Structure does not change organizations, people do. But people cannot do it without process. IT needs models for benchmarking processes, re-engineering techniques, and process design. Typically IT departments live with these tools on a day-to-day basis and have more experience with them than any other group. The trick is for IT to leverage these tools into integrated agents of progressive change - a series of progressive changes that improves life for customers, staff, shareholders, and the community. The changes succeed when IT's partners adopt and implement processes, such as a common project management discipline, to deliver projects. The spirit of mutuality of interest leads to real success in the implementation of enterprise IT.

IT is horizontal, everyone else is vertical. 

If you keep this horizontal/vertical perspective in mind, you will realize the unique value of IT: a way of integrating enterprise-wide processes into unified and holistic processes. These processes become sustainable competitive advantages for the entire organization. 


Climbing to the top of the mountain is a lot of work. But the view is spectacular. 


~