Responsible IT conversations

In my last post, I was pondering the problems in the communication process between users and technology assitance providers - problems that are so pervasive they have given rise to a whole series of internet jokes. The jokes all portray the technologist as the long-sufferering recipient of inadequate communication - if only the users could say what her or she means, everything would be fine. The techy whines that users are changing are requirements between communications, doesn't know a thing about computers, and fail to accurately convey what they want, or what problems are occuring. The problem with this picture is the techy's passivity: she assumes that the user alone is responsible for articulating his concerns. Only after they are articulated will the techy become responsible for providing a solution. But what if both parties accept full responsibility for both sides of the conversation? On the one hand, the technologist needs to accept that it is indeed difficult for users to be clear about IT issues, and be willing to invest time and effort into pulling out the complete picture when a support request is being made. It's part of the assistance we provide. The technologist also needs to accept that requirements will indeed shift inconveniently during a project, and that while there is no way to prevent this, there are many ways to adapt to it. Indeed, the current emphasis on "agile" methodologies is based in part on recognizing that requirements are always in flux. But the users could improve the IT conversation by taking additional responsibility as well. Just as the technolgists share responsibility for articulating the request, the users share responsibility for resolving it. And I really am just talking about responsibility, not of technical acumen. I can't tell you the number of times a user has said to me "I tried to do this, but I got a message". What did the message say? "I don't know, I didn't read it". Another form of responsibility is to take an active role in knowledge support relating to the Information System - user training, documentation of procedures and systems, and so on. We had a user call us from Boston once to ask if we knew which of the computers on their new rack was the database server. We had no idea that they HAD a new rack. Oops - I've fallen back into telling stupid user stories - but you see, they have nothing to do with intelligence or knowledge. They have nothing to do with stupid users, and everything to do with the organization taking ownership of its own system. This also means taking ownership of requirements shift. The Executive Director of a client once asked one of our programmers when we'd be able to quit making adjustments to the software. "This has been going on for years! When will this system be done?". My colleague answered him, "As soon as you quit growing and stop getting all these new ideas!" But it's easy for users to see each change they request as fixing an inadequacy in the system. This is the wrong conversation to be having. Quite a while ago, Chuck Bryan compared the typical technology conversation to the kid's swimming game Marco Polo. The person who is “It“ closes their eyes and yells out “Marco,“ and other players yell out “Polo. The “It“ player moves in the general direction of “Polo“ and then calls out “Marco“ again. By this time, the “Polo“ player has moved, and yells out “Polo“ in a new location. All I'm suggesting is the Polo's should admit they are moving. And Marco should open his darn eyes! Tags: nptech, agile, tech_support