A few months ago I was a speaker in front of a group of CIOs, discussing some of the issues facing IT organizations. One of the CIOs asked me what he could do to better communicate his problems to his business users, who seemed to have trouble understanding the difficulties associated with making changes to software. I suggested that he rephrase the problems in the users' terms instead of using the traditional IT terminology. This is fairly common advice, but I'm always amazed at how few people actually use this approach. As IT people we keep falling back on the language we use with our peers, instead of trying to understand the business user's point of view, and explaining things in user terms.

In the last couple of months, I've seen two interesting examples of explaining IT in user terms. At Southern Company, CIO Becky Blalock had a breakthrough in communication when she explained IT in terms that are more understandable at a power generation company. She told her business users that just as Southern Company uses coal to generate power and then distribute the power to its customers, the Southern Company IT organization uses data to generate information and then distribute it to the business users. The business users got the point, and they began to understand some of the similarities between power distribution and the distribution of information.

At The Home Depot, Chief IT Architect Barbara Sanders uses a similar approach to define the stages that a new technology goes through before it's implemented in a live production environment. Her architecture organization issues "building permits" to pilot projects for new technologies, and then delivers a "certificate of occupancy" when the pilot is proven and the technology is ready for general release. Everyone at Home Depot understands exactly what that means, and there are far fewer questions about why a new technology isn't yet in use.

I've used similar approaches myself. At an architectural firm that specialized in designing college campuses and the buildings that go with them, I explained a plan for a future intranet by showing a campus metaphor for the intranet. Users enter the intranet through the "quad" in the middle of the campus, and then enter various "buildings" (subsystems), always coming back to the quad to navigate from building to building. I identified virtual classrooms for training, a "history department" that keeps records of the buildings the firm has designed in the past, a virtual library of white papers and presentations, an engineering library of details for Computer Aided Design (CAD), and even a transit station for "public transportation" to take the intranet user to selected areas of the Internet. By translating difficult technical concepts like home pages, databases, and gateways into terms with which the architects were familiar, I was able to help the firm understand the benefits of an intranet, as well as some of the issues they would encounter during construction.

For a lower level of explanation, I've often tried to relate IT issues to things that are familiar to the average person. For example, I've frequently used a plumbing analogy to help explain why a system change is so difficult. I describe a hypothetical house-building project, and ask why it might be a big problem if the homeowner changes the location of a bathroom after the wallboard is up. The answer is obvious to most people, yet the concept of a difficult system maintenance change (like expanding a purchase order number) is in no way intuitive to these same individuals. Using the plumbing analogy makes the issues clear.

Similarly, most people seem to be able to relate to an example of trying to add four additional floors to a house that has a foundation designed for a single floor; they know that such a change will necessitate some major foundation work. But it's usually extremely difficult to directly explain why, for example, a system designed in Microsoft Access for a single user can't be easily expanded to be available for hundreds of users on an intranet.

For additional perspective, think of the problems that doctors have in telling their patients about complex diseases and their treatment. The best doctors are able to get their message across using examples from cars, plumbing, electrical circuits, construction, and other generally understood processes. Other doctors just throw medical jargon at you and expect you to figure it out. Which kind of doctor inspires more trust? Which kind of doctor would you rather have do your surgery? Amazingly, we base our opinion of a surgeon's competence not on his or her surgical abilities, but on the ability to communicate with the patient.

IT is the same kind of thing. Since business users can't judge our technical ability, they base their judgments of us on our ability to communicate clearly. Communication is an important part of every project, but it's especially important when your business users don't understand what their IT organizations do for them. The next time you have to explain something, try using an analogy that your users can better understand. You'll find that you communicate better, and you'll get a lot more support.

2004 MakingITclear, Inc. This article was originally published in the November, 2004 issue of the MakingITclear Newsletter, a free monthly email newsletter published by MakingITclear, Inc. MakingITclear is a registered trademark of MakingITclear, Inc.