Use Contextual techniques whenever you need hard evidence and a good understanding of what real people really do.
In development process terms, Contextual techniques fit best before design, either evaluating previous versions of the product, competitors' products, or current non-computerized work practices that the system is intended to support.
In methodological terms, you should use Contextual techniques whenever you've got a good focus, a problem of appropriate complexity. A slightly different slant on this is the contrast between the work-of-the-work versus the work-of-the-tool (Holtzblatt and Jones, 1993). The work-of-the-tool is what you need to do to use some particular tool to accomplish a task. The work-of-the-work are those tasks you must accomplish to do the work, irrespective of what tools are used. Most traditional evaluation methods concentrate on the work-of-the-tool. Contextual techniques address the work-of-the-work. No matter how easy to use a piece of software is, if it doesn't do the sort of things I do, it is not usable and I have no use for it.
In organizational terms, the time to use Contextual techniques is when you've got the time and opportunity. A month is not an unreasonable amount of time for doing your twenty interviews and analyzing the results. Plus you need to consider the time it will take to locate your target users and negotiate the various organizational hurdles. What qualifies as a good opportunity depends on the organiztion in which you find yourself. On the one hand, the time pressure will be less if you are evaluating an existing product with the intent of informing a future release. However, there may be more of an openness to new methods on a project that is branching out into a new area for the company, as there will be more of a willingness to admit that nobody knows what is really going on in that area, and a subsequent acceptance of the need to find out.