I do some web site management on the side, mostly for my church, whose site I recently inherited. I was asking one of the ministry leaders for content for an extremely outdated portion of the site. Her response was one I’ve heard countless times before, both as an analyst and as a programmer, but I seldom hear discussed. She was hesitant to tell me what she was after because she doesn’t do a lot with computers.

Of course, when we are working on building a solution or an organization, whether it be a large enterprise class system, or a small website, many of our customers will not be extremely computer literate. Some day that will change to some degree, but the reality is that it will never change completely. In order to bridge the gap between end user and programmer, the analyst grew up, either as an IT function or within the business. Frequently, on many projects, you end up with the analyst in IT, and someone who is functionally an analyst in the business (often known as the super user). Their jobs are to take what they understand the requirements of the business and translate them into something that programmers/developers can deal with. Along the way, however, end users tend to disappear from the process. The assumption is that their super user will be able to do the job.

I’ve stated before that the super users (and for that matter the IT business analysts) are usually lacking the necessary skills to perform all of tasks assigned to them in the process of implementing an IT solution. That is still very much the case, but even a highly skilled super user or business analyst needs to keep in mind that a key part of their job must be engaging the key stakeholders in the process. The key stakeholders have a vision, or at the very least, a notion of what’s not working. However, frequently their lack of computer saavy leads them to believe that they have little of value to add. I suspect they have been told too many times in the past that what they’d like is simply not possible, so they’ve grown to think that there is no point in asking. The analysts and super users, however, must come to the realization that they can’t take no for an answer.

At the same time, you can’t simply just force stakeholders to tell you what they want. Often it helps to prime the pump a little bit. In that earlier blog, I mentioned this book, which is focused on capability envisioning, not merely requirements. The authors prefer a process where the IT folks (analysts or super users) come to the table with a knowledge of what sorts of technical possibilities exist and engage the user in a discussion about what they would like to see from a business perspective (either opportunities to do more or problems that need to be fixed). In the example that triggered this post, I started down that road by suggesting some possibilities of things we could do with the page, and asking questions like, “what do you want to communicate?”, “what are the most important elements of the program?”, etc. Once that process started, then the feedback started. Interestingly, that may be one of the most important skills that an analyst can acquire.