Justifying Contextual Inquiry
I had an interesting discussion with a colleague, who challenged me to explain the need for holding a large number of observations, each of which lasted a long time, and each of which involved the users showing our analysts the concrete details of their interactions with the existing software systems. (The judgments "large" and "long time" were relative to the user interviews that my colleague conducted for a previous, similar project. For my project, my team conducted nine contextual inquiries, each of which lasted about two hours.) He noted that his project, which was successful by all accounts, involved interviewing only two business users for about 45 minutes each. He further made the conscious decision to avoid getting bogged down in the minutiae of the current software systems in place, as he didn't want to bias his approach, and he chose instead to focus on understanding the overall business objectives for the system to be developed. Once he understood the objectives, he designed a system that would meet them, and as it turned out, the system was very well received by the user community.
My response was that, excepting the issue of whether it makes sense to observe concrete details with the existing system, the differences between our approaches are differences of degree rather than of kind. We both interviewed users and wanted to understand the objectives and processes; I simply interviewed more, and did so in a more in-depth way. There are at least two risk-reducing reasons for interviewing more people, which I mentioned earlier: generalizations about work practice are more strongly supported if there are more users, and you need a fair number of users if you have a large project team and you want your team to take ownership of understanding the business domain. That reduces risk because it's harder (though not at all impossible) for an entire team to be wrong than it is for a single person to be wrong.
Similarly, there are at least two reasons for interviewing people in-depth, and even for understanding the details of whatever current software system is in place. First, users don't clearly separate mechanism from process, and so it is the rare user who can explain the process in abstract terms without mentioning which specific systems they access, which buttons they press, etc. The business process expresses itself through the user's interaction with the existing software systems, and it is up to the analyst to extract that from the session. Second, the solution that the IT team ultimately presents will be evaluated against the current system, and so it makes sense for the IT team to understand that system. Further, the IT team will want to be able to point to data justifying deviations from the status quo, and will also want to explain the benefits of the new approach as measured against the old. This too requires understanding the old system.
Finally, I pointed out that the business directors and managers were pleased that we were involving their employees in this way, and that my team members also seemed pleased to be able to contribute to discussions on "the business" in a way that they weren't able to do with projects that I ran using a more traditional methodology (tech manager collects requirements by talking with business managers). Each team member was able to make valuable contributions, as no one person had a general view of the task domain, even though it turned out that the task domain was fairly uniform for the set of users in question. In this case, this had more to do with variation across users (i.e., differences in what they chose to highlight) than it did with variation in the work itself.
