One hundred rules for NASA project managers (1995) [pdf] | Hacker News Reader

One hundred rules for NASA project managers (1995) [pdf]

oliverlehmann.com

188 pointstablet34 comments

Spent 5 years at one of NASA's prime subcontractors, positions ranging from mechanical CAD jockey to assistant program director.

This "guide" was written by a gentleman in the last years of his 37 year career. I saw many similar guides/reviews of programs that were way behind sched and over budget. All written by retiring/recently retired upper management, they'd come in under a budget provided by some government oversight company or consulting group. They'd poke sticks into every group, come up with their assessment, then drop it on the active program director's desk. The program director would assign actions, the gov't oversight group could check off the box that it participated in "program saving" guidance, and 3 months later everyone forgets/ignores the input.

I think this guide paints a clear picture of how inefficient and misguided gov't run programs are for those that can stand to see it. The irony is so strong in the title, it's verging on sad. It is hard to believe anything ground breaking or efficient was ever created by following a "100 Rules" guide.

As a federal state and municipal contractor of ten years I can say from experience the higher up in government you go the more exponentially wasteful their policies are and meaningless the average task becomes.

For example I spent maddening weeks changing fonts back and forth and trying to get the same number of records per page (as the original access version) in a report 100,000 pages long that nobody will ever read, print, or analyze with tools. (it was a PDF)

I am convinced they were taking sheets from the report I wrote and printing them out on transparencies which were overlaid on the old report so they could tell me to move things around one pixel at a time.

This is by no metrics isolated to governmental run organizations but something you will see in many larger organizations. It's a consequence amongst other things of having deep pockets and not tight enough feedback loops IMHO.

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.

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?

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.

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)

I wouldn't call them "best practice guidelines". "Wouldn't it be nice if..." is probably a better description.

Or maybe, "I think it would be cool if...".

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.

Rule 96: "Experience may be fine, but testing is better. Knowing something will work never takes the place of proving that it will."

my motto: "It's only as good as it has been tested to be"

I'm constantly reminded of this, most recently when I noticed my local Fire Dept doing checks on their specialty (gas powered) chainsaw tool every tuesday around 7:45am as I drive by on my commute.

Speaking as someone who has worked for NASA and is familiar with "testing", that rule makes me a little queasy.

Can you explain?

Admittedly, I don't work on flight or science related things, but testing here means taking relatively cursory look at things so that you can check off items on a list. It's extremely happy-path focused.

Obligatory: "Beware of bugs in the above code; I have only proved it correct, not tried it."

http://en.wikiquote.org/wiki/Donald_Knuth

"Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc."

Zing.

I couldn't tell if that was intended to be a slight against the avg. American's tenuous grasp on English, or if they literally meant people from the Americas which may include Central and South America.

Probably literally meant people from the US. In English, standard usage assumes "America" to mean "USA", and references to the region are referred to as "the Americas" (plural), with the north/central/south regions being considered largely separate. There's very little value in referencing the majority of the residents of the western hemisphere as "Americans", as there's really nothing they have in common beyond that.

There is more than a little tongue-in-cheekedness about this document. The fact that it's a humourous slight against Americans (that is, citizens and residents of the United States of America) doesn't mean it isn't true.

More importantly, it's making the point that all communications are fraught with lack of clarity and misunderstanding.

As this very subthread is evidence.

As the aeronautical engineer friend of mine says when you ask him why he's writing web UI's rather than building rockets, which is what he trained to do: "Because this flies and that doesn't."

Rule 30: "It is mainly the incompetent that don't like to show off their work."

Rule (-30): "Good work speaks for itself."

Jesus.

Number 56: "The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble."

"External reviews are scheduled at the worst possible time, therefore, keep an up-to-date set of business and technical data so that you can rapidly respond. Not having up-to-date data should be cause for dismissal."

If you read 'external reviews' as 'fundraising rounds'...then no disagreement there.

People reading this strictly as an indictment of government work are utterly missing the point. My own career spans decades, large companies and small, old and new, and a few stints of government work as well.

The thing this reminds me most of all is a very time-worn copy of Arthur Bloch's Murphy's Law: and other reasons things go ƃuoɹʍ. You can find most them here: http://www.murphyslaws.net/edition.htm

It was at a highway rest stop on one of the long Interstate routes favored by aerospace engineers in the late 1970s, and I still think I've learned more practical knowledge from it than just about any other book I've ever read, though realizing the import of some of the apparently humorous laws (many of which were actually said with all seriousness in their original expression) has taken a long time to register.

Rule 24 from the Nasa piece should register with many here:

One must pay close attention to workaholics - if they get going in the wrong direction, they can do a lot of damage in a short time. It is possible to overload them and cause premature burnout but hard to determine if the load is too much, since much of it is self generated. It is important to make sure such people take enough time off and that the workload does not exceed 1 1/4 to 1 1/2 times what is normal.

Another huge lesson, particularly for the younger people on HN, is that if you find yourself working at an organization in which the rules here are being consistently violated, you are working at a sick organization and/or have a grossly incompetent manager.

I've had management all over the map. One of the best had a great deal of government (and military) experience. He wasn't overtly technical (though he knew more than he let on), but saw when goals were and weren't being met, and would ensure that resources were made available and barriers removed, often without asking. Two specific instances come to mind: I required additional systems permissions for a specific task, told him, he was on the phone to the responsible person and I had the privileges within ten minutes (I've worked at shops where this is a 24-48 hour, or longer, task). Where my workflow made heavy use of multiple terminals and screenspace, and secondary large monitors were a rarity, when one freed up it was on my desk the next day without my asking for it.

And when business conditions went south (there were a lot of people hit), our parting conversation was direct, to the point, and personal. What I didn't have to deal with was weeks or months of anxiety leading up to that point.

The gig following that one, with a young manager in start-up space, was a polar opposite, and, at least from a management perspective, a strongly negative contrast (though not the worst I've had).

Just reminds me of this https://www.youtube.com/watch?v=wvnr52Muwo8

Coming with background in service company in oil field and I should say I benefited from reading this script a lot

"Space is not a big playing field." - had me fooled.

As an industry, it's not. Most industries aren't.

Nor are many online discussion sites, as a bonus ProTip.

Reply on news.ycombinator.com