Project Management AntiPattern - PMs who write specs

One of my favorite organizational mistakes, and I've seen this one MANY times, is asking your Project Manager to write a functional spec for the IT application you are writing.  I've seen this so often, I'd consider it a Project Management anti-pattern.

Why is this bad?  Because there needs to be discourse (and disagreement) between the person who describes the system and the person who manages the project that fulfills it.  When you are building a house, the contractor and the architect discuss, argue, and debate.  When you are building a bridge, the engineering designers have constant feedback on the bridge as it comes into being.  Not so with IT projects where the project manager writes the functional specification.

I'm honestly astonished when I run into this.  I've seen experienced project managers simply assert that "this is the right way," without even considering the conflict of interest that goes on in this condition.  If one person decides both the "stuff" that is in a project and the "plan" needed to complete it, the kinds of junk that comes out the other end is amazingly bad.  I don't care how "engaged" your business customer is. 

The answer is for the spec to be written by business analysts who WORK FOR the business, REPORT TO the business, and SIT IN MEETINGS WITH the business.  Some folks like for these folks to be paid by IT but report to the business, but personally I don't agree.  Real benefits come when this is actually a business person:  They have to have more than IT responsibilities.  They have to understand the processes and constraints used by the business.  They have to be available to IT at a very deep level.  And they have to be financially responsible for success.

More importantly, the spec is not dictated by this person to the PM.  The spec is written by this person.  Not just owned... written.

Caveat: I'm not saying that this (bad) practice does or doesn't happen within Microsoft IT.  It definitely happens.