I'm considering sitting with the end-users and observing them while the work for a day to better understand the software requirements.
Before I try this, I'm hoping someone can provide a list of best practices, suggestions on when this approach is more/less suitable than simply interviewing the users, and notes from your own experiences using job observation/shadowing.
References to other sites or recollections of your own personal experience are both welcome.
Best Answer
This approach is almost always more suitable than simply interviewing the users.
Why?
Because users lie. Sometimes it's not malicious. They just can't tell a proper story.
They do this two ways.
They have little vision; they don't really know what a new application could possibly do. They don't describe things that include real, overall business value. Instead, they describe details of how it's implemented right now, however bad that implementation is.
This is perhaps most common, since most users that aren't "business owners" or "executives" have been delegated a piece of a larger operation.
They have an overly grandiose vision; they imagine all kinds of things, some of which are impossible. They don't describe things that include real, overall business value. Instead, they fantasize about some job that exists only in their imagination.
This is distressing because it leads to requirements that -- sometimes -- can't even be tested. Or, if they can concoct test cases, debate arises within the user organization. Or, if one organization agrees, other organizations can't provide the required data.
Most often, however, this leads to systems that are needlessly overspecified. Often a "first sprint" provides a workable solution that does everything required but is very little like the grandiose vision.
Because users lie. Sometimes it is malicious. They refuse to tell a proper story and instead simply avoid providing concrete details. Evasive users are particular difficult to deal with, since there is no straight story. When you try to detail your understanding, you've always got several key features completely wrong -- even though you've provided verbatim words from the interview.
Best Practices
Collect actual documents (files or paper documents) that reflect the user's real workflow with real data. Nothing -- nothing -- beats actual data to provide the nuanced complexities of the daily job.
Try to discern real business value from workarounds due to bad software created by people who didn't do any job observation. It seems like 25%-50% of an application is tweaks and interfaces required to correct problems in other applications.
When observing someone solving a problem (or working around a problem) you'll have to discover the root cause. You won't discover this through job observation or interviewing. You'll discover this through a combination of observation, interviewing and code reviews.
In some cases, whole departments are created to work around software limitations. That department does not create value -- it avoids the cost of bad software. Job Observation can lead to a streamlined workaround. But it's still a workaround for a more fundamental root-cause problem.