Prepared to Launch: Growing up PM at NASA

Originally documented by Jerry Madden NASA Associate Director

Modified for ProjectManagement.com by David A. Maynard

Who is Jerry Madden?

During Jerry Madden's 37-year career at NASA, the federal agency launched its first satellite, achieved the first lunar landing, and deployed the Hubble telescope. It also innovated outside the edges, bringing satellite TV, air-cushioned sneakers, and solar panels to the masses. In other words, NASA was an idea factory running at full steam.

Madden, who retired in 1995 as associate director of flight projects at Goddard Space Flight Center, was critical to the operation. As one of NASA's premiere project managers, he saw to it that great ideas became tangible innovations; he coordinated the technology, teams, and bureaucracy needed to propel science forward.

Along the way, Madden also curated and penned a now-infamous list of 128 lessons for project managers, which still circulates through NASA today.

Source of this document

You can download the original (free) at http://go.nasa.gov/2fBULlK  But some of it is NASA-specific, or at least Aerospace-specific.   I’ve modified these slightly to make them less “application specific” and more in-tune with current Project Management theory.  I’m taking them about 25 at a time  - the actual count depends upon my editing.

From the original document: “None of these are original--It's just that we don't know where they were stolen from!”

The same goes for me!

Discussions

I think the community here can add / subtract and modified from these.  Please feel free to post corrections, insults, additions, or general impressions.  Maybe even pick out your favorites. 

                                      Endeavour Flight Deck (My Old Office...)

The Project Manager

107.        Gentlemen and ladies can get things done just as well as bastards. What is needed is a strong will and respect – not “strong arm” tactics. It must be admitted that “strong arm tactics” does work but leaves a residue that must be cleaned up.

108.        Though most of us in our youth have heard the poem by Benjamin Franklin that states “for want of a nail the race was lost”, few of us realize that most space failures have a similar origin. It is the common place items that tend to be overlooked and thus do us in. The tough and difficult tasks are normally done well.  The simple and easy tasks seem to be the ones done sloppily.

109.        In the “old NASA”, a job done within schedule and cost was deemed to be simple. The present NASA wants to push the start of the art, be innovative, and be a risk taker but stay on schedule and cost. One gets the feeling that either the new jobs will be simple or that the reign of saints has finally occurred.

110.        Meetings, meetings – A Projects Manager’s staff meeting should last 5 minutes – minimum/1-hour max.   Less than 5 minutes and you probably didn’t need the meeting – longer than 1 hour, it becomes a bull session.

112.        Taking too many people to visit a supplier or puts them in the entertainment business – not the hardware or software business.

113.        Too many engineers get in the habit of supporting support suppliers and of using them as a crutch. In many cases, it is getting to the point where one must wonder who is who.

114.        Reviews, meetings, and reality have little in common.

115.        You should always check to see how long a change or action takes to get to the implementer – this time should be measured in hours and not days.

116.        Let your staff argue you into doing something even if you intended to do it anyway. It gives them the feeling that they won one! There are a lot of advantages to gamesmanship if no one detects the game.

117.        Some suppliers are good, some are bad, but they seem to change places over time, making the past no guarantee of the future; thus, constant vigilance is a project requirement.

118.        It is rare that a supplier does not know your budget and does not intend to get every bit of it from you.  This is why you have to constantly pay attention to the manpower they use and to judge their activities in order to assure that they are not overloading the system.

119.        People tend to ask for what they think they can get and not what they need.

120.        Too much cost data on a proposal can blind you to the real risks or forgotten items. On a project we thoroughly knew, we spent 6 months validating the cost, had rooms full of data, and presented our findings to Headquarters. Two weeks later, the supplier found an “Oh I forgot” that costs $30 million. One should look at how past programs spent their money to try to avoid these traps.

121.        We estimated we needed about 20 percent contingency on previously flown subsystems and about 40 percent to 50 percent on new ones. The ratio was about right except the order was reversed.

122.        There are some small companies that make the same subsystem correctly every time because the same people do it. There are some large companies that can never make the same unit correctly every time because different people do the work each time. 

123.        Too many project managers think a spoken agreement carries the same weight as one put in writing. It doesn’t. People vanish and change positions. Important decisions must be documented.

124.        Make sure everyone knows what the requirements are and understands them.  You must have the right people look at requirements. A bunch of managers and salesmen nodding agreement to requirements should not make you feel safe.

125.        Too many people at believe the myth that you can reduce the food to the horse every day till you get a horse that requires no food. They try to do the same with projects which eventually end up as dead as the horse.

126.        The project manager who is the smartest man on his project has done a lousy job of recruitment.

Originally documented by Jerry Madden NASA Associate Director

Modified for ProjectManagement.com by David A. Maynard

Who is Jerry Madden?

During Jerry Madden's 37-year career at NASA, the federal agency launched its first satellite, achieved the first lunar landing, and deployed the Hubble telescope. It also innovated outside the edges, bringing satellite TV, air-cushioned sneakers, and solar panels to the masses. In other words, NASA was an idea factory running at full steam.

Madden, who retired in 1995 as associate director of flight projects at Goddard Space Flight Center, was critical to the operation. As one of NASA's premiere project managers, he saw to it that great ideas became tangible innovations; he coordinated the technology, teams, and bureaucracy needed to propel science forward.

Along the way, Madden also curated and penned a now-infamous list of 128 lessons for project managers, which still circulates through NASA today.

Source of this document

You can download the original (free) at http://go.nasa.gov/2fBULlK  But some of it is NASA-specific, or at least Aerospace-specific.   I’ve modified these slightly to make them less “application specific” and more in-tune with current Project Management theory.  I’m taking them about 25 at a time  - the actual count depends upon my editing.

From the original document: “None of these are original--It's just that we don't know where they were stolen from!”

The same goes for me!

Discussions

I think the community here can add / subtract and modified from these.  Please feel free to post corrections, insults, additions, or general impressions.  Maybe even pick out your favorites.

The Project Manager

52. Many managers, just because they have the scientists their project, forget that the scientists and their stakeholders many times have easier access to top management than a Project Manager does.
     
53. Most scientists are rational unless you endanger their chance to do their experiment. Most engineers are rational unless you endanger their chance to design.  However, they will work with you if they believe you are telling them the truth.  This includes reducing their own plans.
     
54. Cooperative efforts require good communications and early warning systems. A project manager should try to keep the stakeholders aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The stakeholders should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides their stakeholders will be treated in kind and will be considered a person of little integrity.
     
55. All problems are solvable in time, so make sure you have enough schedule contingency-- if you don't, the next project manager that takes your place will.
     
56. Abbreviations are often a pain. Each project has many. This calls on senior management to know a great many!  Use abbreviations sparingly in presentations unless your objective is to confuse.
     
57. Occasionally things go right--the lesson learned here is: Try to duplicate that which works.
     
58. Running does not take the place of thinking. For yourself, you must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.
     
59. Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss but, if you constantly must solve someone's problems, you are working for them!
     
60. We have developed a set of people whose self-interest is more paramount than the work -  or at least it appears.  It seems to the older managers that the newer ones are more interested in form than in substance. The question is “are old managers right or just old?”
     
61. One problem new project managers face is that everyone wants to solve their problems. Old project managers were told by senior management-"solve your damn problems; that is what we hired you to do."
     
62. Remember, it is often easier to do foolish paperwork than to fight the need for it. Fight only if it will save much future work.
     
63. Know your management--some like a good joke; others only like a joke if they tell it.
     
64. Integrity means your subordinates trust you.
     
65. You cannot watch everything. What you can watch is the people. They must know you will not accept a poor job.
     
66. Next year is always the year with adequate funding and schedule--next year arrives on the 50th year of your career.
     
67. The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.
     
68. External reviews are scheduled at the worst possible time: therefore, keep an up-to date set of technical data so that you can rapidly respond. Having to update business data - the night before a review - should be cause for dismissal.
     
69. Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses--just state facts.
     
70. Try to find a way for the reviews to work for you.
     
71. Knowledge is often confounded by test. Computer models have hidden flaws, not the least of which is poor input data.
     
72. Today one must push the state of the art: be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long, as the ground rules are established up front and maintained.
     
73. Most of yesteryear's projects overran because of poor estimates and not because of mistakes. Getting better estimates may not lower cost but will improve NASA's business reputation.
     
74. A scientific proposal takes about 9 months to put together. It takes NASA HQ about 9 months to a year to select the winning proposals. Then, it takes 3 to 4 years to sell the project. This means 5 to 6 years after the initial thoughts, the real work starts. Managers, for some strange reason, do not understand why a scientist wants to build something different than proposed. Managers are strange people.
     
75. There are rare times when only one person to do the job. These are in technical areas that are more art and skill than normal. Cherish these people and employ their services when necessary as soon as possible. Getting the work done by someone else takes two to three times longer, and the product is normally below standard.
     
76. Software has all the parameters of hardware, i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc. It has the added feature that it is hard as hell to determine it is not flawed. Get the basic system working and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world the newer version works. It is necessary to have contingency plans for software.
     
77. History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards.