well, a business degree in IT maybe, not that it helps. the point of the mythical man-month was that, in a factory system, you can throw more labor at a job and get it done faster. (Rosenberg's Dreaming in Code has a great chapter on how the people building Chandler ended up throwing labor at the late project, evne though they knew better.)
The formula that works in a factory system doesn't work in software development: hence, the myth of the man month.
There's ramp up time, for one: you have to figure out what the project's about, what you're supposed to do, drop in to figure out someone else's code (and for about 75% get rattled because they didn't do it *your* way [the not-built/invented-here-syndrome] which costs in the aggravation and foot-dragging), etc. There's the communication overhead too: now you have 6 developers to coordinate, meet with at daily standups, twice as many code reviews, etc.
in my limited experience, managers who have an IT business degree know about the mythical man month. they're just unable or unwilling to explain it to traditional business types. so they throw labor at a late project or, more commonly, one that is getting out of scope, hoping that it might just work out. never does.
I read an interesting book, Pragmatic Thinking and Learning, a couple of months ago. The author's premise was that software development suffered from, among other things, a problem where people are treated as interchangeable parts. You can move software devs around willy-nilly. Indeed, recently, my org decided to re-org. Under the banner of cross-training, they swapped people around, pulling them out of their areas of expertise and throwing them into an area they'd never worked in. They didn't provide training. They didn't change project deadlines either.
So, one day this guy and I are having a meeting. his lead runs into the conference room and says, "holy shit, X is missing from all our site's pages. something we did a month ago caused the problem and QA never caught it."
turns out that the guy, who was recently swapped around like a part, did something he shouldn't have done b/c he didn't understand the architecture. not his fault, no one trained him. of course, the swapping was done to make sure we were cross-trained. but apparently, that is supposed to happen by osmosis, while the deadlines remain the same.
so, he spent five hours figuring out the architecture to fix the problem. The problem itself would have taken 5 minutes to fix had he known the architecture - and, of course, it never would happened in the first place had he known.
I said, "yo, if anyone bitches at you about this, just tell them, 'that was my five hours of cross-training, thank ya very much.' I'm going to start printing out 'I've been cross-trained certifications' after every one of these incidents."
Same crap has happened countless times since.
shag
-- http://cleandraws.com Wear Clean Draws ('coz there's 5 million ways to kill a CEO)