I've been with the agency for 5 years. Rules 76 and 78 kind of made me laugh, since projects and centers stab each other in the back all the time. But I think similar dynamics exist in any sufficiently large organization. Mastery of internal politics eventually becomes one of the most highly valued skills you can have, if you stay on for the long haul.
NASA centers (and "competency centers") are almost completely unrelated to each other. Policies and procedures at one center have nothing to do with any of the others, and HQ may say, "thou shalt do this", but there's no guarantee a given center will pay more than lip service to it. And not even that if their politics-fu is strong enough.
Oh, and JPL is completely unrelated to the rest of NASA. To the extent that I'm debating removing "the rest of" from that previous sentence.
I've spent much of my professional career at NASA Goddard and I'd have to agree with this for the most part. My former group worked well with a group at Ames, but my current group pissed off JPL by taking some work they wanted. So it goes...
I've got six years at the "NASA Enterprise Applications Competency Center", NEACC (not to be confused with the North-East Alabama Community College, NEACC), which is at Marshall but really, sort of, part of HQ. We frequently get to do really bad things because the people at Johnson, for example, want to do things completely differently from the people at Kennedy.
At startups, marketing and engineering (finding what the customer wants, and building it quickly) are what drives success. As firms grow, internal coordination becomes more important.
Success at "Making sure Excel is backwards compatible to every version of Windows and chip for the past 10 years, and has the same look and feel as every other Microsoft application" requires a lot of other skills: organizational design and management, project management, and (gasp!) even politics. The problem is when you reward those things, by default you disincent other things. Eventually people overjudge the political. But you need political skills to make things happen.
I'm getting flashbacks to a long project where we had 4 centers testing different versions of a certain bit of kit (all 4 for TRL3-5, then a review selecting one for TRL6+).
Feel like I could write a book on the bullshit that occurred and that was just one fairly minor project. Suffice to say, lots of disingenuous 'helping' that was really just working out where exactly in the back to place the knife.
Do you actually have to follow these rules? Is this a kind of "best practice guideline" that PMs only sorta follow? Or is this rulebook ever/sometimes used as a procedural weapon between PMs battling for resources, budgets or influence?
These are largely a list of "best practices", yes. Influence and budgetary conflicts between projects and centers can happen from the "shop floor" all the way up to the capital building. NASA's is one of the most earmarked budgets in the federal government, usually shaped by a few key congressmen with centers in their districts. So a budgetary struggle usually ends in some equilibrium between the deemed "core competencies" of a center pitching new work, and the ability of their congressfolk to direct work or facility construction in spite of technical considerations.
(I should probably say that despite the politics involved, I really like what I do. Still the best job I've had by a long shot)
Of course you don't have to follow these. They are the kind of lessons world-weary managers/nerds like to pass around for fun and possible enlightenment.
