Prepared to Launch: Growing up PM at NASA

These are things that my mind drifts to occasionally.   They are real, they happened to me while managing projects, but had a larger life-changing effect than just a Project’s lessons learned or contribution to OPA.   They affected my personality, my outlook on life and the way my brain works.k

A couple I’ve already blogged about, but in the light of “how we managed projects.”  This blog entry starts a series of how managing projects at NASA changed my life.  I’m sure the same thing has happened to you.  You learn from managing projects and those lessons apply to more than your next project.  They go into your brain and are “compiled” into your personality.  I sat down and focused on life-changing lessons by managing Projects.  

I was 22, a New Yorker and an Engineer who had just started working at NASA, I pretty much knew everything.  All you had to do was ask me and I’d tell you.   Doubting that I’d done a job correctly or if it could be done better, or even that I understood exactly what needed to be done NEVER HAPPENED.  The WBS?  It was perfect.  Risks?  They were all considered and under control.   Requirements traced to the designs = perfect job.   

When I left work, I never needed to think about things like: “Was that smart?”  “Should we change the way we’re approaching a problem.”

NASAs method of having constructive independent reviews of your project plans, decisions, risks, finances, and resources (I’ve blogged about this) taught me that these people weren’t out to hurt me (but it often felt like it).  The purpose of the review was for the reviewee.  Not to entertain the crowd of reviewers.  They were doing this for ME and for NASA. 

The sum of the group conducting the reviews was much smarter than I was.  They saw things I (and the project team) never would have seen.  The reviews were to make sure we as an organization were doing smart things and hopefully not forgetting things. 

Life Lesson:  Seek help from others.  Even if the others disagree with you, find fault in your approach, doubt your assumptions, and generally embarrass you in front of a lot of people and your boss.  After a year or so of this, I realized the best answer to a critical comment is “Thank you!”

This created a life-long habit of waking up at odd hours of the night, and quickly writing down something that I *thought* the reviewers would ask me.  I could hear them in my head.  Things like “Have you checked that supplier’s financial stability?  You’re going to be placing a large order and they have to be able to handle it.”  I’d write that down, or send an email to the team right then.   Actually, I can hear a (in my head) a member of the review group right now as I type this.  

Ask the good folks at ProjectManagement.com!  It not uncommon to get an email from me at 2:25 in the morning saying: “I just thought of something.”  The funny part is that it’s not really me that thought of something – it’s the review committee still rattling around in my head. 

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. 

                                               Space Shuttle Atlantis

The Project Manager

79.   Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. 

80.   A project manager is not the monitor of the work but should be the driver. Contractors don't fail, NASA does, and that is why one must be proactive in support.  This is also why a low score damages the government project manager as much as the contractor's manager because it means they are not doing their job.

81.   There is no greater motivation than giving a-good person their piece of the puzzle to control however a pat on the back or an award helps.

82.   Morale of a contractor's personnel is important to the project manager.  Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware built by them.  You should take an active role in motivating all personnel on the project.

83.   People who monitor work and don't help get it done, never seem to know exactly what is going on.

84.   Never assume someone knows something or has done something unless you have asked them.  Even the obvious is overlooked or ignored on occasion--especially in a high-stress activity.

85.   Don't assume you know why senior management has done something.  If you feel you need to know, ask. You get some amazing answers that will dumbfound you.

86.   If you have someone who doesn't look, ask, and analyze, ask them to transfer.

87.   Bastards, gentlemen, and ladies can be project manager. Lost souls, procrastinators, and wishy-washers cannot.

88.   A person's time is very important. You must be careful as a manager that you realize the value of other people's time.   You must, where possible, shield your staff from unnecessary work, i.e., some requests should be ignored or a refusal sent to the requester.

89.   A good technician, quality inspector, and strawboss are more important in obtaining a good product than all the paper and reviews.

90.   The seeds of problems are laid down early. Initial planning is the most vital part of a project.  Review of most failed projects or of project problems indicates that the disasters were well planned to happen from the start.

91.   A comfortable project manager is one waiting for his next assignment or one on the verge of failure.  Job security is not normal to project management.

93.    Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better.

94.   Whoever said beggars can't be choosers doesn't understand project management.  Many times, it is better to trust to luck than to get known poor support.

97.   Talk is not cheap.  The best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.

98.   Projects require teamwork to succeed. Remember most teams have a coach and not a boss, but the coach still must call some of the plays.

99.   In the rush to get things done, it is always important to remember who you work for. Blindsiding your  boss will not be to your benefit in the long run.

100.    Over-engineering is common.  Engineers like puzzles and mazes--try to make them keep their designs simple.

101.   Never make a decision from a cartoon / drawing.  Look at the actual hardware or what real information is available, such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.

102.   A company’s age can be estimated by the number of reports and meetings it has. The older it gets, the more the paperwork increases and the less product is delivered per dollar. Many people have suggested that a company self-destruct every 25 years and be reborn starting from scratch.

103.   False starts are normal in today’s environment. More than ever, in this type of environment, one must keep an ear open for the starting gun and be prepared to move out in quick and orderly fashion once it is sounded. In the past, too many false starts have resulted in the project not hearing the real starting gun or jumping off and falling on its face.

104.   There are still some individuals who think important decisions are made in meetings. This is rarely the case. Normally, the decision-makers meet over lunch or have a brief meeting to decide the issue and then (at a meeting called to discuss the issue) make it appear that the decision was made because of the meeting.

105.    In political decisions, do not look for logic – look for politics.

106.    In dealing with international partners, the usual strategy is to go 1 day early, meet with your counterpart, discuss all issues to be brought up at a meeting, arrive at an agreeable response (or a decision to table the issue for later discussion), and agree not to take any firm positions on any new issues brought up at the meeting. This makes it appear to the rest of the world that you and your counterpart are of one mind and that the work is in good hands. All disputes are held behind closed doors with the minimum number of participants. 

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. 

The Second 25 Lesson's Learned

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.  It's been handed around, updated, parts removed and maintained for years.  I’ve modified these slightly to make them less “application specific” and more in-tune with current Project Management theory. I’m taking them 25 at a time and below are numbers 26 to 51. 

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!

This time, I’ve bolded  the ones I like…. 

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

26. Suppliers tend to size up their project counterparts, and staff accordingly. If they think yours are clunkers, they will take their poorer people to put on your project.

27. Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have been, and what the reality is. Documents are normally a static picture in time which is outdated rapidly.

28. Remember who the customer is and what their objectives are. Communicate with them when you need  to change anything of significance.

29. In case of a failure:
    1. Make a timeline of events and include everything that is known;
    2. Put down known facts--check every theory against them;
    3. Don't beat the data until it confesses, know when to stop trying to force-fit a scenario;
    4. Do not arrive at a conclusion too rapidly. Make sure any deviation from the norm is explained.  Remember the wrong conclusion is prologue to the next failure;
    5. Know when to stop.

30. Remember the Program Manager has the right to make decisions, even if you think they are wrong.  Tell the Program Manager what you think but, if they still want it done their way, do your best to make sure the outcome is successful.

31. Redundancy in hardware can be a fiction. We are adept at building things to be identical so that if one fails, the other will also fail. Make sure all hardware is treated as if it were one of a kind and needed for mission success.

32. Don't be afraid to fail or you will not succeed, but always work at your skill to recover.  Part of that skill is knowing who can help.

33. Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.

34. People have reasons for doing things the way they do them.  Most people want to do a good job, and if they don't, the problem is they probably don't know how or exactly what is expected.

35. The Project Manager may not know how to do the work, but they must know what they want.

36. The Project Manager should find out what they expect and want if they don't know. A blind leader tends to go in circles.

37. A puzzle is hard to discern from just one piece, so don't be surprised if team members deprived of information reach the wrong conclusion.

38. Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.

39. The amount of reviews and reports are proportional to management's understanding, i.e., the less management knows or understands the activities, the more it requires reviews and reports. It is necessary in this type of environment to make sure the data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence.

40. In olden times, engineers had hands-on experience, technicians understood how things worked, what it was supposed to do.  But today only the computer knows for sure, and it's not talking.

41. Not using computer modeling for systems is a great mistake, but forgetting the computer simulates thinking is still greater.

42. Management principles haven’t changed. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.

43. It is mainly the incompetent that don't like to show off their work.

44. Whoever you deal with, deal fairly. You may be surprised how often you must work with the same people. Better they respect you than carry a grudge.

45. Failure is a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.

46. You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the Project Manager. There are simple courses available to learn computerese, communicationese, and all the rest of the modern ese's of the world.  You can't manage if you don't understand what is being said or written.

47. Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to take adequate steps so that there are no misinterpretations of what is said.

48. NASA Management Instructions are written by another NASA employee like yourself; therefore, challenge them if they don't make sense.  It is possible another employee will rewrite them or waive them for you.

49. A working meeting has about six people attending.  Meetings larger than are mainly for information transfer.

50. Being friendly with a supplier is fine--being a friend of a supplier is dangerous to your objectivity.
     
51. NASA must work at a fixed price; therefore, "requirements creep" has become a deadly sin.