
So What Do I Do? While most surveys can't pass the rigorous tests of statistical validity, they can be helpful in identifying areas of concern. Take a 10 percent sample of a population of 1,000 users. If you find that 90 percent of the respondents are dissatisfied with current e-mail services, you cannot conclude with statistical confidence that 90 percent of all your users are dissatisfied. But you can be fairly confident that you've identified a problem of some kind. Unfortunately, while surveys can effectively identify general problems, they don't usually provide much depth or insight. To gather that information, you need to employ a more interactive methodology.
The most common technique for gathering in-depth information on a topic is to assemble a focus group. Focus groups are quite small, usually fewer than 10 people, and are charged with exploring an issue in some depth. Unlike a survey, which asks how users feel about a set of services, the focus group is designed to provide insights into why they feel the way they do.
Unlike a survey administrator, who is expected to be a dispassionate information-gatherer, the focus-group facilitator plays a critical role in probing for information. A successful facilitator needs to possess a solid understanding of the subject matter, as well as skill in asking key questions. Equally important, the facilitator needs to show talent for suppressing input by individuals who attempt to dominate all discussions.
It is almost never safe to draw conclusions based on the input of a single focus group, so replication becomes an important part of this process. If you hear the same concerns expressed by multiple groups, each probed independently, you're probably onto something significant.
Institutionalized Input The value of surveys and focus groups for taking a pulse on user concerns about IT services should not be minimized. Unfortunately, the most significant concerns that users express are almost always difficult to resolve, though they may look incredibly easy from the IT users' perspective. For example, it's not unreasonable for users to request a single login ID and password for all systems, but they don't realize fulfilling that request is anything but simple. Usually, it's a matter of trade-offs--you can't solve $200 worth of problems with a $100 budget.
But, it is often difficult for IT managers to explain why a seemingly simple problem can't be solved. If you could make the user understand the technical complexities, there might be hope. But if the user could understand, you'd probably hire him or her for an IT position. Alternatively, you can attempt to convince the user, based on his or her trust of your knowledge, that the problem is a tough one to resolve. Unfortunately, in most large organizations, trust of high-paid technocrats is not a pervasive sentiment--suspicion and skepticism are much more common.
It is precisely this set of organizational politics that makes a decentralized model of IT support so essential. Although this approach may not be as efficient as a centralized model, the distributed IT support specialist-- typically a departmental computer and network administrator (DCNA) working full-time in a user's department--is much more likely to garner trust than the central IT staffer. Further, because these DCNAs work with the same end users every day, they acquire a good understanding of which users have legitimate networking concerns.
By systematically gathering the input of DCNAs, central IT staff can often get a much better handle on the issues and, by working together, generate some ideas for practical solutions for their departments. And at times when there are no workable short-term solutions, the DCNA can be more credible in communicating that message to users.
Ah, but just in case you thought I was living in a dream world, let me acknowledge that managing this relationship between central IT staff and technically knowledgeable DCNAs is tricky, to say the least. First, all DCNAs will not share a common perspective on the most sensible technical directions for the enterprise as a whole. This should come as no surprise, given the diversity of views that is often present within the central IT organization. Second, and probably more significant, many DCNAs will be unwilling to act as mouthpieces for naysayers within the IT organization, even if they personally agree with their complaints. At issue is their credibility within their own departments, and aligning oneself too closely with central IT can have a detrimental impact on one's career, day-to-day job or both.
Get Your Head Out of the Sand For better or for worse, a large number of IT decision-makers have simply given up on the notion of developing systematic mechanisms that involve end users, or even their proxies, in the information-management decision-making process. Instead, they often adopt a paternalistic position of trusting their own instincts. As well-intentioned as their motivations may be, it is difficult to imagine how they can maintain the credibility of the IT organization under such a decision-making perspective--that is, unless all the breaks go its way, which they never do. And you don't need a survey to draw that conclusion with a high level of certainty.
Send your comments on this column to Dave Molta at dmolta@nwc.com.
|