Project Management

Prepared to Launch: Growing up PM at NASA

by
NASA has a long tradition of project management; it's well documented and practiced daily. This blog will explore the author's 20+ years of experience working on space projects to a strict (and documented) set of processes by exploring actual projects and their results. You'll find that while NASA's project and program management standards are similar to PMI's standards, there are quite a few differences.

About this Blog

RSS

Recent Posts

Terminal Area Energy Management (TAEM)

NASA Project Management Challenge

Teams of vastly different skilled people CAN work together

Notice the small things. The rewards are inversely proportional

LIFE LESSONS: Learned as a Project Manager at NASA #2

Categories

Academy of Project Management, Ask the Expert, chapter 11, Congress 2016 Ask an Expert, Congress 2018 Ask the Expert, Diversity, Global Congress 2016, NASA Project Standards, Organizational Risk, PM Lessons Learned, pmbok chapter 11, pmbok guide, PMI Global Congress - 2016, pmp, Project Confidence Level, Project Resources other than Budget, REP, risk, Risk Management, risk register, Virtual PM Challenge

Date

Teams of vastly different skilled people CAN work together

linkedin twitter facebook Request to reuse this  

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.   They affected my personality, my outlook on life and the way my brain works.

A couple I’ve already blogged about, but in the light of “how we managed projects.”  These blogs are 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

Background

The issue to be solved was the Shuttle orbited upside down, backwards – and with ZERO fuel remaining – and it needed to de-orbit and land on a runway.   The shuttle did have maneuvering fuel and a *LOT* of potential energy.   Knowing those limitations, create a model for the safe return of the orbiter to one of several runways.   This problem became known as TAEM (pronounced: as TAME) which stands for Terminal (stopping) Energy Management.  The potential energy of the orbiter needed to be converted to kinetic energy – precisely.

Oribiter To find a solution to this problem involved aerodynamics, physics, mathematics, engineering and software. A large and highly skilled team worked on TAEM.

A computer program onboard the shuttle made the last adjustments of speed and altitude as the spacecraft started to land. The vehicle began re-entry by firing the Orbital Maneuvering System (OMS) while flying upside down, backward, and in the opposite direction to orbital motion about six minutes before touchdown.  The TAEM software constantly checked the shuttle's position, attitude, velocity, and descent angle, and automatically guides the craft into its final approach to the runway.

If you're really into this stuff, you can read the NASA report on TAEM here 

Working together

There were a LOT of people involved in the formulation of the problem and the solution.  The group had what is called: “Informational Diversity.”  Informational diversity is variations of skills, abilities, and knowledge among team members. This type of diversity is based on different functional, educational and industry backgrounds that constitute information and knowledge resources upon which the team draws.

Conflict

Naturally, there was conflict within the team.  But team conflict can be a good thing.   The traditional view of conflict was developed in the 19th century, prevalent through the 1940s and still exists today

  • Conflict is bad
  • Always has a negative effect on projects
  • Performance declines as conflict increases
  • Conflict must be avoided!

It was the manager’s job to reduce, suppress or eliminate any type of conflict! 

But, there is another approach!

In the “Interactionist View” Conflict is natural and inevitable in all organizations, it may have either a positive or negative effect, and Project Managers should focus on managing conflict rather than eliminating it. 

During the TAEM development project, conflict was encouraged by:

  • Asking tough questions
  • Invite members with different views to speak
  • Appointing a “Advocatus Diaboli” (Devil’s Advocate)
  • Consider alternatives.

Overall rules for managing a diverse team

1. Establish a Sense of Mission

One my most favorite stories that illustrates a sense of mission is when President John F. Kennedy was visiting NASA headquarters for the first time, in 1961. While touring the facility, he introduced himself to a janitor who was mopping the floor and asked him what he did at NASA. The janitor replied, “I’m helping put a man on the moon!”  The janitor got it. He understood the vision, and his part in it, and he had purpose.

Project Mission Thoughts..

  • Why does this project exist?
  • Why is it important?
  • Will It will be used?
  • Did I had a part in fulfilling the mission?
  • Believe it, Say it, Do it, Repeat

2. Establish a Communications Framework

The old-fashioned way of doing this is by posting things on a wall.  It works!  And it’s still used today.

Today, there are many electronic dashboards that serve the same purpose – but, to me – lack the same feel as paper pinned to a wall.

3. Create and live by a set of Team Guidelines

This sounds corny, but it works!  As a group, we would invent, add, remove and modify a set of team guidelines.  Yes, even adults with super-egos can abide by a set of guidelines.  But you can’t just write them down once and distribute them.  You, as a group, need to keep them in mind and remind others of a “rules violation.”

Here the rules we developed from a different team, I wasn’t smart enough to capture other project’s rules.

  1. Neatness doesn’t count; accuracy does
  2. If in doubt people know about it, write it down
  3. Bad news is good; good news is great!
  4. Full truth is permitted
  5. Keep your charts up to date at all times
  6. Don’t roll over or give up
  7. Read other’s charts!
  8. Stay focused
  9. All meetings are held here – on time!

 

The Project Teams worked Well and TAME worked well.

Posted on: February 09, 2017 02:23 PM | Permalink | Comments (4)

Notice the small things. The rewards are inversely proportional

linkedin twitter facebook Request to reuse this  

The Smallest Thing Can Cause Major Problems, and take a long time to find & fix

Life Lessons I learned as a Project Manager 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.   They affected my personality, my outlook on life and the way my brain works.

A couple I’ve already blogged about, but in the light of “how we managed projects.”  These blogs are 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

BACKGROUND

The primary caution and warning system is designed to warn the crew of conditions that may adversely affect orbiter operations. The system consists of hardware and electronics that provide the crew with both visual and aural cues when a system exceeds predefined operating limits.

The primary system's visual cues consist of four master alarm lights, a 40-light array on panel F7 and a 120-light array on panel R13.  The caution and warning system interfaces with the auxiliary power units, data processing system, environmental control and life support system, electrical power system, flight control system, guidance and navigation, hydraulics, main propulsion system, reaction control system, orbital maneuvering system and payloads.   

THE PROBLEM

One day one of the indicators on the caution and warning panel was “stuck on.”  I can’t remember which one it was, but it didn’t take long to discover that it SHOULDN’T be on.  It was a false indication of a problem.  Think of a Project Management dashboard that shows a problem – that doesn’t really exist.  ANNOYING.  And, in this case it was VERY annoying to the crew.  Everyone wants to fly in something that has all its parts working.  I know I do!  The false indication seemed to suggest there was something in the Avionics or Glass displays that was wrong.  That’s how I got involved. 

What could cause a false indication? 

The shuttle used MANY MIL-standard 61 pin connectors for the cables.  A GREAT many of them.   They are very rugged, reliable and only semi-difficult to work with.  And the electrical systems on the orbiter are complex with lengthy runs, packed cables and difficult to get to.  Unplugging a cable is something like standing on your head while trying to unscrew a garden hose.   Meanwhile schedules were slipping, deadlines being missed, testing delayed, EVERYONE was aware of the problem and asked me about it all the time.  It moved to the top of the “squawk” list.  Again, I was encountering a “Significant Emotional Event.” 

Finding the problem took  a long, long time.  Scope here, meter there, inspect visually here.  That doesn’t sound too difficult but take a look at the wiring we had.  And there’s lots of connectors!!  There was a problem in there someplace.  The wires were neatly laced, the pins were crimped on and the 61 pin connectors were all in the right places.   Every time a lacing was cut, it had to be re-done and re-inspected.

My Project:  THE LIGHT WAS ON.  FIX IT!

The charter: Manage a group of about 12 people to scientifically and methodically look for the problem.  

We laid out a plan, devised ways to “split the problem” succcussively into halves until we could isolate it. 

This was a very boring task.  Not thrilling, not doing engineering,  not math…  But it was a problem and it had to be fixed.   After about a week I found it.

IT WAS A BENT PIN

The life lesson learned from this rather simple but important project was that sometimes it’s the littlest thing that can set your project back and ruin your schedule.  But you can’t give up – you must “press ahead.”   I think this is  true of nearly every project.

In other words: “Notice the small things. The rewards are inversely proportional.” -  Liz Vassey

By the way, I can still tie the NASA standard lacing knot.  I use it for everything from tying up bags of leaves to fixing my lawn mower.

Here's what I consider to be the "standard" lacing knot -- a single (not running) lacing knot. 

 

Posted on: January 17, 2017 07:21 PM | Permalink | Comments (11)

LIFE LESSONS: Learned as a Project Manager at NASA #2

linkedin twitter facebook Request to reuse this  

These  stories are  are real, they happened to me while managing projects at NASA and were a life-changing event.   They affected my personality, my outlook on life and the way my brain works.

A couple I’ve already blogged about, but in the light of “how we managed projects.”  These blogs are 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

BACKGROUND

Early in the Shuttle Program, (the third launch or STS-3) an important mission was for the astronauts to fly Space Shuttle Columbia for its longest stay in space thus far (7 days).  In preparation for that mission, the astronauts planned to spend 40 hours – without stop - in the Shuttle Mission Simulator (SMS) practicing on-orbit operations.

The very large simulator was a mixture of flight hardware and commercial equipment.  The commercial equipment (several very large main frames and 20 or so “Front End Processors” – we’d call them servers today) had the job of creating the environment to make the flight computers believe they were, indeed on-orbit. 

The primary objectives of the mission were to continue testing the "Canadarm" Remote Manipulator System (RMS), and to carry out extensive thermal testing of Columbia by exposing its tail, nose and top to the Sun for varying periods of time.   And, we were running an important and useful simulation using the SMS.  The simulation tested the flight software and hardware and helped the crew establish their procedures, processes and help generally “ring out” the system. There other purposes as well.  Experiments included a plasma diagnostic package, a mono-disperse latex reactor experiment, the first study of insects in space, and many more.  

The Crew in the Simulator During the 7 Day Trial

Everyone had a role in the simulation, Mission Control, Remote tracking stations, experts – I was told there were 800 people world-wide participating in the 40-hour simulation.  Many were “on the loop” or plugged into the audio network we’ve all heard many times on TV.  I had a headset and could hear the network communications.

THE PROBLEM

We wanted to run the simulation for the full 7 days.  But, the computer systems failed just before 40 hours each time.  Not good!  The clever single flight computer voting scheme, didn’t work, the system simply came to a complete HALT – always at about the same time.  Maybe 38 hours, maybe 39 hours…   Emotions flared, crew members were not amused and would leave the building and everyone would yell about something.  This happened about 4 or five hours. Imagine 800 + angry people, all with a headset!

The work-around the first few times was to pause the simulation, set the event “clocks” to 40+ hours and continue.  This worried several of us a great deal.   Why couldn’t get past 40 hours?  Was it the simulator or the flight hardware, the complex simulated environment we invented (the main frames and servers).

AN APPROACH

I built a system (cleverly called “Test data”) so I could monitor the traffic from our main frames to the flight computers.  The idea was to catch whatever was causing the problem.  My little system had probes all over, wires running around to each of the 12+ (large) computers, a disk drive, monitor and a nice hidden spot in the corner of the SMS complex.    For days, I watched the data flow from the main frame to the flight computers. 

After a few more failed simulations, I was convinced I spotted the problem.  (not to get too nerdy, but the main frames were 60-bit single precision words and the servers were 32 bit words.  We had designed hardware to do the “stack and pack” to and from 32 bits and 60 bit words.   I looked like it failed after 30+ hours, but only once!  Once was enough to crash the system.  A real needle in a haystack.

I wanted to stop the simulation right then so I could try and see what caused it.  So…. I did.   I pulled emergency stop.    800 people went off line because young Dave shut down everything. 

GOOD NEWS / BAD NEWS

The good news is that I captured the data and could point to the cause (heat!).  We fixed it easily and within a day or so.   The bad news is that this was one of many of what we used to call “A significant Emotional Event” for me.   I was instantly very, very unpopular with a LOT of folks.  Remember, everyone was already on edge when I pulled the stop.  I imagine people around the world (all the tracking stations) were using my name in short sentences. 

THE AFTERMATH

About a week later, my wife and I were shopping for a new vacuum cleaner at Sears, and one of the crew (pictured above) came up to me and said that I did the right thing. “It was a decisive and bold move well worth the risk.  Thanks Dave!   Later, I was given a hand-made award by the astronaut office for what I did.   It’s very crudely made, and fading now, but it’s my favorite award.  Signed by the crew and John Young (head astronaut at the time).

AWARD FOR REACHING 60 HOURS, 6 MINUTES AND 12 SECONDS.  :) 

THE LIFE LESSON LEARNED

If you believe something is the right thing to do, and the time is right – DO IT.  Don’t wait, don’t hesitate, don’t worry about repercussions.  However, think about your action ahead of time, make sure you’ve considered other options, make sure you know what you’re doing, but DO IT! Have the courage of your convictions.

Posted on: January 06, 2017 05:43 PM | Permalink | Comments (5)

LIFE Lessons Learned as a Project Manager at NASA.

linkedin twitter facebook Request to reuse this  

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.  

Seek Advice from others

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. 

Posted on: December 16, 2016 04:36 PM | Permalink | Comments (6)

A NASA Project Manager’s Lessons Learned – Part 4

linkedin twitter facebook Request to reuse this  

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. 

Image result for orberter photo

                                               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. 

Posted on: December 08, 2016 03:01 PM | Permalink | Comments (0)
ADVERTISEMENTS

"When one door closes another door opens; but we often look so long and so regretfully upon the closed door that we do not see the ones which open for us."

- Alexander Graham Bell

ADVERTISEMENT

Sponsors