Not another banjo joke!

What has sixteen legs and three teeth? The front row in a banjo workshop. Mommy, I want to grow up and be a banjo player! Now honey, you know you can't do both. The jokes that come out of our work, whatever it is that we do, can reflect real points of frustration built into the structure of that work. Let's look at technology assistance: there are well-known jokes about the difficulties that occur in IT consulting that have been posted over and over again on the net for years. In the requirements analysis area there is the oft-repeated parody of The Night before Christmas that ends: And the user replied with a snarl and a taunt Its just what I asked for, but not what I want. In the domain of the "help desk" there is the famous problem submission form that begins. 1. Describe the problem. 2. Now describe the problem accurately. 3. Speculate wildly about the cause of the problem. These jokes would not show up over and over again if they did not reflect a problem built into the way we do work. I fretted about these jokes for a while until it began to resonate for me: Each of these pieces describes a situation where the technologist is habitually dissappointed by the quality of information he feels he is getting from his users. The consultant feels he could do his job beautifully, if only the user gave him better information. But since this problem occurs so often, we have to assume the problem is somehow created by the way the work is done - it can't be that users in general just don't know how to communicate. (Unless, of course, they are all banjo players) After all, we are all users. The technologist is looking at communication between the user group and the technology group as being made up of information flows in two directions: if you could just manage to tell me what the problem is, I might be able to tell you how to fix it. The user sees it exactly the same way. I will tell you what I need, and then you can tell me what to do. Maybe this concept is the source of the frustration - instead of two disjunct information streams, perhaps we need a single collaborative knowledge support effort here. Knowledge Management is often looked at as a an effort lying snugly within the organizations' boundaries. But at least three of the most critical tasks in IT consulting - trouble resolution, requirements analysis, and training - explicitly involve collaborative use of knowledge by the users and the technology assistants. These groups may be within the same organization, or in different companies. But we need to envision a shared knowledge support infrastructure that crosses the boundary between techies and users if we want to improve these fundemental IT interactions. p.s. only a few more days to see Picturing the Banjo at the Corcoran Gallery! Tags: nptech, km, IT_consulting