The Concept of Proof of Concept.
I had not participated in many projects which had a POC stage, or joined projects after that stage, so I may be missing the point here.
Customers tend to have a "waste not want not" frame of mind: If we write code - it had damn well better be used in the production product. "We cannot afford games" so the programming teams should only write code which will stick. "Work smarter not harder" and all that crap.
I try to explain to my customers that code is a living being. I personally think that if I wrote a piece of code and didn't change it at least twice - I did something wrong (HACKed the use of that component or simply didn't use it enough.) Code should be "refactored to patterns" any time it's changed, and it should be changed a lot. Pretending that it is perfect is, as a rule of thumb, stupid. Therefore - I write the best code that I can at any given time, and this probably means that code that I write will be deleted or changed before it reaches production.
Enter the customer.
"We don't pay you good money to just to practice your typing" they say.
Usually I yell enough at them to make them understand the dynamics of code (or just to leave me alone), but what I often fail at is to make them understand the meaning of POC. It is, as I understand it, simply another project, unrelated to the "real" one except that it uses some of the same technologies, products and product interaction.
Customers usually see the POC as the parliminary work of the infrastructure team, and as such - the time spend on the POC should be deducted from the time needed for the project, and that's a hard concept to debunk.
Maybe we should be working differently? Maybe the POC should be written as the basis for the actual product components? Maybe a POC should not be billable to the client? Should the client pay for something which we do simply because we don't know if what we offered to provide can actually work? Or is there a magic bullet to make the customer understand? (Or am I just wrong?)