Thought I should round up my answer more even-handedly.

In practice, I feel managers and programmers (or any "technical" personnel) are as much a victim as vilain, since most of them were never taught how to work with each other.

The CS curriculum normally focuses on programming, nothing much on how to work with people. (Like, a programmer might always complain a req spec wasn't "perfect," instead of helping a non-techie how to write a spec.)

A biz program teaches quite a bit of concepts and theories, but not every biz student came out with good implemenation knowledge (theoretical or pragmatic). I usually found them lack of any concept of "stable system" and why you can't meaningful fix and improve a system that's not "stable." Instead, management by crisis or mgt by (annoying) cheerleading is a common style, which often amounts to destablizing a system.

It would be better if mgrs and programmers have overlapping knowledge that helps bridge their communication gap. In an ideal world, we could have the following:

Stylized view of the distribution of knowledge and skill sets

	knowledge\skill sets
	strategic thinking	biz sense	req elicit (aka mind- reading?)	req analysis	design	programming	QA (conceptual and/or technical)
biz/acc't mgr
proj mgr
sys analyst1.
lead programmer1.
programmer
what to do/know:	if a project/client strategically or technologically compatible & complementing the current sys or products...	how a project contributes to the bottomline, or to the current system or products...	ask questions that lead to actionable requirements...	if each step has adequate input-output params, generalize/ minimize the flowchart...	generalize, minimize...	(assume you know best here)	explain to mgr why the one who programmed shouldn't be the one who tests...
sample artifacts:	a sensible executive talks sensibly...	biz case, justifies proj ...	flowchart (readable by clients) w/ indications of input-output params at each step...	flowchart (meaningful to programmers), conceptual class diagram...	class diagram, activity diagram, mock screens...	(assume you know best here)	test scripts (manual or automated)

^1.sys analyst -- system-wide architectural issues
  lead programmer -- individual applications

If people don't come in readily with what it takes, we just have to train them in house (if feasible).

See that, on one hand, the major reasons of the software projects' failure (as a business) are "managerial," rather than "technical;" on the other hand, managerial decision process is a collective effort, not just by titled managers.