Prototypes "evolving" into "real" programs isnt the fault of the prototypes at all, its the fault of those who use them, or their team leaders. Prototypes are quite useful to define a common "this is what we are talking about" stage, to show something people can point at and say "I want that" or "I don't want that", all specs and words on paper are sometimes hard to visualise for non-technical people.

The prototype is definitely not there to expand upon, its part of the "build one to throw away" philosphy.. If thats hard to do, then one should create them in another unrelated language, or just draw them even, a drawn up design on paper is a prototype in a way too.

Your typical scenario isn't bad, but you missed out the part where you go back to Joe and inform him, whereby he tells his manager theres a ballsup, and they figure out who it is that does want/is getting reports etc etc. Discussing specs with whomever is concerned is a great ider (tho I'd have just called them all into one meeting), but usually doesnt allow you to just eliminate the problem like that.

C.