There's no doubt the customer drives development, but how they drive development is up to the chickens (http://www.implementingscrum.com/ for what a chicken is).

Edgar, a PMP project manager with a huge set of credentials and years experience was showing John the statement of work for their current project. He said, "John i made sure that certain parts of it were vague so that we'd have leeway in what we could make so we can meet the schedule".

Is it really the policy of PMP professionals to build a statement of work that is so huge but so vague that it can easily be re-interpreted?

YES

Why? because the purpose of a statement of work in a non-agile environment is to interpret the customer's need into something the Project manager is positive he can build within that timebox... ie something he's already seen built before. NOT what the customer actually wants, mind you.

Also, this sets up the gunsights on the customer for the blame game when the product is delivered and doesn't meet the customer's expectations BUT matches the statement of work!

How many times has a customer said "Well you built what i asked for, but not what i wanted"  ?

By definition, i don't think a statement of work can be written to suit an agile team because it clearly defines scope (or it should anyhow, though do they ever accurately do so in software?).

Instead of a SoW, try making contracts with the customer that define HOW the team, including the customer's team member, will work together to bring about the software in an iterative manner.

If you absolutely must have a statement of work(government contracts?), do the XP planning game up front and figure out the high level user stories, have the customer prioritize them, have the engineers estimate them, build an iteration schedule and make that the statement of work.