REG NASA-LLIS-1956-2008 Lessons Learned 100+ Lessons Learned for Project Managers.pdf

1、Lessons Learned Entry: 1956Lesson Info:a71 Lesson Number: 1956a71 Lesson Date: 2008-9-30a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Jerry Maddena71 POC Email: unknown (retired)a71 POC Phone: unknownSubject: 100+ Lessons Learned for Project Managers Abstract: Je

2、rry Madden, the former Associate Director of Flight Projects at NASA Goddard Space Flight Center (GSFC), collected 122 lesson learned nuggets from a variety of sources that are instructive to managers of NASA spaceflight projects. These aphorisms should be accepted where they may provide insight int

3、o NASA project management success.Description of Driving Event: Jerry Madden retired in 1995 as Associate Director of Flight Projects at NASA Goddard Space Flight Center (GSFC). Over his 37 years with NASA, he collected the following lesson learned nuggets that are instructive to managers of NASA sp

4、aceflight projects. As he obtained them from a variety of sources, they are not clearly traceable to any specific set of originating projects or “driving events.“ Arguably, it is difficult to identify project management lessons learned that are widely applicable but not obvious, and these should be

5、accepted where they may provide insight into NASA project management success. This material first appeared in the October 2003 issue of NASAs ASK Magazine, which now lists 122 of these aphorisms (Reference (1): Design Engineering 1. There is no such thing as previously flown hardware, i.e., the peop

6、le who build the next unit probably never saw the previous unit; there are probably minor changes; the operational environment has probably changed; and the people who check the unit out will in most cases Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-

7、,-,-not understand the unit or the test equipment. 2. Most equipment works “as built,“ i.e., not as the designer planned. This is due to layout of the design, poor understanding on the designers part, or poor understanding of component specifications.3. In case of a failure, make a timeline of event

8、s and include everything that is known. Put down known facts, and check every theory against them. Dont beat the data until it confesses: i.e., know when to stop trying to force-fit a scenario. Do not arrive at a conclusion too rapidly. Make sure any deviation from the norm is explained; remember th

9、e wrong conclusion is prologue to the next failure. Know when to stop.4. 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 in a build as if it were one of a kind and needed for mi

10、ssion success.5. Dont 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.6. Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.7. Reviews are for the revi

11、ewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.8. The amount of reviews and reports are proportional to managements understanding, i.e., the less management knows or understands the activities, the more it requires reviews and reports. It is necessary in thi

12、s 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 anyones intelligence.9. In olden times, engineers had hands-on experience, technicians understood how the electro

13、nics worked and what it was supposed to do, and layout technicians knew too. But today only the computer knows for sure, and its not talking.10. Mistakes are all right, but failure is not. Failure is just a mistake you cant recover from; therefore, try to create contingency plans and alternate appro

14、aches for the items or plans that have high risk.11. The old NASA pushed the limits of technology and science; therefore, it did not worry about “requirements creep“ or over-runs. The new NASA has to work as if all are fixed price; therefore, “requirements creep“ has become a deadly sin.12. The numb

15、er of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-means you should be able

16、to construct a set of slides that only needs to be shuffled from presentation to presentation.13. Occasionally things go right. The lesson learned here is: try to duplicate that which works.14. The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they a

17、re in trouble. Engineers are born optimists.15. 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 should be cause for dismissal.16. Hide nothing from the reviewers. Their repu

18、tation and yours is on the line. Expose all the warts and pimples. Dont offer excuses: just state facts.17. NASA is establishing a set of reviewers and a set of reviews. Once firmly established, the system will fight to stay alive, so make the most of it. Try to find a way for the reviews to work fo

19、r you.18. Knowledge is often confounded by test. Computer models have hidden flaws, not the least of which is poor input data.19. Software now has taken on all the parameters of hardware, i.e., requirement creep, high percent-age of flight mission cost, need for quality control, need for validation

20、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 c

21、ontingency plans for software.20. 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.21. The seeds of problems are laid down early. Initial planning i

22、s 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.22. 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 rig

23、ht levels is deadly.23. Never make a decision from a cartoon. 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.24. Though most of us in our youth have heard the po

24、em that states “for want of a nail the race Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-was lost,“ few of us realize that most space failures have a similar origin. It is the commonplace items that tend to be overlooked and thus do us in. The tou

25、gh and difficult tasks are normally done well. The simple and easy tasks seem to be the ones done sloppily.25. Reviews, meetings, and reality have little in common.Planning, Decision-making, Documentation, and Reporting 26. Wrong decisions made early can be salvaged, but “right“ decisions made late

26、cannot. 27. Never make excuses; instead, present plans of actions to be taken. 28. Never try to get even for some slight by another project. It is not good form. It puts you on the same level as the other person, and often ends up hindering the project getting done. 29. If you cultivate too much ego

27、tism, you may find it difficult to change your position, especially if your personnel tell you that you are wrong. You should instill an attitude on the project whereby your personnel know they can tell you of wrong decisions. 30. One of the advantages of NASA in the early days was the fact that eve

28、ryone knew that the facts that we were absolutely sure of could be wrong. 31. Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure, but luck favors the competent, hard-working manager. 32. Documentation does not take the

29、 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. 33. You cannot be ignorant of the language of the area you manage or with that of areas with w

30、hich you interface. Education is a must for the modern manager. There are simple courses available to learn “computerese,“ “communicationese,“ and all the rest of the modern eses of the world. You cant manage if you dont understand what is being said or written. 34. All problems are solvable in time

31、, so make sure you have enough schedule contingency. If you dont, the next project manager that takes your place will. 35. Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know a couple hundred thousand. Use them sparingly in presentatio

32、ns unless your objective is to confuse. 36. 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. 37. Next year is always the year with adequate funding and schedule. Next ye

33、ar arrives on the Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-50th year of your career. 38. 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 grou

34、nd rules, such as funding profile and schedule, are established up front and maintained. 39. Most of yesteryears projects overran because of poor estimates and not because of mistakes. Getting better estimates may not lower cost but will improve NASAs business reputation. Actually, there is a high p

35、robability that the cost of getting better estimates will increase cost and assure a higher profit to industry, unless the fee is reduced to reflect lower risk on the part of industry. A better reputation is necessary in the present environment. 40. People who monitor work and dont help get it done,

36、 never seem to know exactly what is going on. 41. Bastards, gentlemen, and ladies can be project manager. Lost souls, procrastinators, and “wishywashers“ cannot. 42. A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews. 43

37、. A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management. 44. False starts are normal in todays environment. More than ever, in this type of environment, one must keep an ear open for the starting gun and be p

38、repared 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. 45. There are still some individuals who think important decisions are made in meetings. This

39、 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 is made as a result of this discussion. 46. Too many project managers think a spoken agreement carries t

40、he same weight as one put in writing. It doesnt. People vanish and change positions. Important decisions must be documented.Managing Project Staff 47. The source of most problems is people, but damned if they will admit it. Know the people working on your project, so you know what the real weak spot

41、s are. 48. Most managers succeed on the strength and skill of their staff. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-49. A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on him

42、self. 50. One must pay 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, causing premature burnout, but hard to determine if the load is too much, since much of it is self-generated. It is important to ma

43、ke 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. 51. Never undercut your staff in public; i.e., dont make decisions on work that you have given them to do in public meetings. Even if you direct a change, never take the responsibility

44、 for implementing away from your staff. 52. The project has many resources within itself. There probably are five to ten system engineers considering all the contractors and instrument developers. This is a powerful resource that can be used to attack problems. 53. A project manager should visit eve

45、ryone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work, and the best proof is for the manager to visit

46、them and see first hand what they are doing. 54. If you have a problem that requires the addition of people to solve, you should approach recruiting people like a cook who has under-salted, i.e., a little at a time. 55. Other than original budget information prior to the Presidents submittal to Cong

47、ress, there is probably no secret information on the project, so dont treat anything like it is secret. Everyone does better if they can see the whole picture, so dont hide any of it from anyone. 56. People have reasons for doing things the way they do them. Most people want to do a good job, and if

48、 they dont, the problem is they probably dont know how or exactly what is expected. 57. A puzzle is hard to discern from just one piece, so dont be surprised if team members deprived of information reach the wrong conclusion. 58. Not using modern techniques like computer systems is a great mistake,

49、but forgetting the computer simulates thinking is still greater. 59. Management principles are still the same. 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. 60. It is mainly the incompetent that dont like to show off their work. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-