Because Lindbergh was the first to do it solo

And Alcock and Brown weren't the first to make the flight over the Atlantic, although they were the first to do a non-stop. The crew of the NC-4 did it first (but they used more than one aircraft) Alcock and Brown did have balls - climbing out on the wings to chip off the ice as they flew.

Sorry, but I work with two teams of 10 year old girls, and the topic of discussion among the moms was what sport bras work and where to buy them, preferred deodarants, and the preferred Under Armour for a girl who is wearing white shorts which can be seen through when wet.

Admittedly, this is a sample size of 22 healthy athletic American girls who eat well, but of the 22, only one or two are not showing signs of puberty.

And I wish I could erase the knowledge regarding who has started growing hair. Certain things a dad/coach just does NOT need to know. Moms/wives like to torment the men around them. Just like their teenage selves. Need brain bleach.

You should see the girls flirt with the younger coaches, especially those who have English accents. And then tell me hormones haven't hit.

That's like saying "Go learn Java (or C# or Ruby or...) only because that's what I and a lot of people say is the realistic approach." THEY'RE ALL TOOLS FOR THE ARSENAL, AND YOU SHOULD BE FAMILIAR WITH ALL OF THEM.

Just as what language you use is a choice depending on the skills of the team, the hardware at the company, and the project at hand; the project management style depends on the team, the company, the requirements, etc. Based on my 20 years of experience, WHAT PM approach you do doesn't matter as much as a good team. I do insist that you have SOME sort of plan/process/framework for requirements management, task analysis, timelines, etc... But I will state that what matters is the team. Once you have the right people, apply the project management framework that works for the team and for the project. And adapt it as needed as things evolve.

As many have said, go to PMI. Take what they say with a grain of salt. (Even though I am a coder, I've taken several of their courses and always gotten value out of them, which is more than I can say of many courses) Because we on slashdot do bring joel spolsky up frequently, I will say Joel has some though provoking posts about project management among many other things (joelonsoftware.com) Not saying I always agree with him - take what he says with a grain of salt...

Management thinks "we need to make a quick hard decision and get moving."

To go through each person on the soon to be cut product line and determine their skill set, look at everyone's past evaluations, and then to cross train them on the new product and get them up to speed will take TIME and MONEY. It's quicker and easier to just cut them. Added bonus: we don't get into arguments about discrimination, who sucked up to which boss, etc.

Hypothetical (well, not really) situation. You've just taken over another company in an acquisition. The company had the same product line as an existing division, so you're going to combine them. The acquired company has 3/4ths more business. The existing division has a reputation of a team that Gets Things Done and Done Well. Existing division uses the same software and hardware as the rest of the company. New company uses different development architecture - I'm talking Java/Unix versus .NET/Windows. What do you standardize on? Who do you keep?

IT people start digging into the architecture and doing comparisons. Business people? They cut it short. They tell IT to stop doing that. The acquired company has more business. Ergo, it will cost more to convert their business to the existing division, so the decision is to standardize on the acquired company's systems. Don't care about the skills sets, the expertise, awards won, etc - we need to make a quick decision and get moving.

And if anyone is hiring, 10% of my group just got laid off (not me). And some of them are good. But they don't know the other system, and we have too many people...