A NASA Project Manager’s Lessons Learned – Part 3

 

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.