Pair Programming Payoff

For a project that runs for, say six months or more, there should no extra development cost on account of pair programming. Period. If there is extra cost, it means pairing is not paying off for you. Pairing should pay off in the following difficult-to-measure ways:

1. Lesser rework during development on account of misunderstood/ill-defined requirements. These things surface quickly when pairs talk to each other.
2. Slight reduction in maintenance cost on account of clearer code. Because every line is now considered readable by at least two people. (more in case of pair rotation)
3. A better detail level design results when each pair acts as a sounding board for the other. Good design reduces cost of future change.
4. Faster/better process of bringing new team members up to speed.
5. Lesser impact of people taking vacations.
6. Lesser bugs in QA, UAT
7. More hours of focused work per day - however professional someone may be it is natural for concentration to wax and wane. Pairing almost always helps here. 
8. Unlike the case of no-pairing, there is no separate code-review activity required
   

How do you figure if there is extra cost? Estimate both ways. The total 'release-lifecycle effort' for the case of pairing should not exceed that of no-pairing. Individual stories may indicate greater effort but that is okay. It is very difficult to do controlled experiments to nail this down. There are some studies but your mileage may vary.

A word of caution when estimating for such comparisons. Remember that on all real projects, actuals mostly exceed estimates. Some of the difference is borne by the client (change control etc) and the rest by the vendor (unpaid overtime etc). You need to have a realistic idea of effort overrun for the case of no-pairing to be able to compare it with the overrun for the case of pairing.

If pairing is resulting in net higher development cost on a long running project, then it simply means (to paraphrase Kent Beck) that the client is getting XP'd on :)