• You're not entirely sure who all of the end users might be.
• You don't want to spend the time gathering this information because (pick one); (a) fact finding will just add days to the duration of the project, (b) you want to give your Prime the impression that you're already hard at work creating what s/he's asked for and/or (c) you believe that Ready, Fire, Aim is the correct sequence.
• You think the project purpose could be influenced away from your Prime's interests (a seemingly bad thing) if you ask for the input of others.
• You think you already know what they want and need.
• You operate under the assumption that end-users should be happy with whatever you create for them (which is the arrogant attitude they'll assume you have if you don't ask).

Why You Should

You help your Prime avoid making a bad investment in a result that may look good on paper (or his mind's eye), but that doesn't have much chance of improving productivity and end-user morale.

You learn from the best informed people (those who do the work) what they need, increasing the likelihood that your Prime will get what s/he's trying to invest in (better profit numbers and/or lower costs through greater productivity).

You know that point at which the ROI (Return On Investment) formula goes negative (as in "You're investing more in the project than you can expect to get out in worthwhile results.") and, consequently, that point at which you should either (a) get much more creative or (b) abandon the project for something with greater promise.

You can give your stakeholders a much better estimate of project return than they could get without the end-user information you've gathered. (Note: Bottom line return estimating is a tough enterprise, but project managers are in a good position to gather that kind of information beforehand and, with a disciplined approach toward comparing estimates with actuals, project managers do become much more accurate ROI estimators.)

You can avoid disrupting end-user "busy times" when the introduction of your project result would reduce productivity and induce resistance.

You can design use training for your project results that builds from what you discover your end users know to a point where your result can be confidently and productively used. (You lose big points by going over familiar ground and/or confusing end users by starting your training at a point that's over their heads).

You choose 'typical' beta testers from the end user population who can point out the problems that their 'typical' work mates will encounter rather than masking problems by choosing the eager overachievers who make your result look easier and better than it really will be.

 

Some Tips On How To

Add any project-specific questions to the general ones listed in the item above. You'll come up with several on your own, but don't fail to capture the questions that crop up during your first end-user interview or two. Because you don't know what you don't know, the questions and observations of end-users will really help you find your blindspots.

Start your end-user fact finding with open probes (planned questions that can't be answered with "yes" or "no") to (a) get them talking, (b) avoid putting words in their mouths, (c) keep from revealing any biases you may have and (d) keep your listening-to-talking ratio to the optimum 70/30.

Ask a summarizing, fact-finding closed probe (a planned question that can only be answered with "yes" or "no") for each question/topic on your list. Then write the answer down (it will aid your memory and signal to the end-user that you'll remember what s/he said).

Meet any resistance with curiosity rather than an argument. Remember, this project just might be a non-starter for reasons that only end users know. If you argue with them, you'll never really find out what you'll need to know to help your Prime not waste money and credibility (yours and his/hers).