NASA: 100+ Lessons Learned for Project Managers

Jerry 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.

While these are mostly around NASA projects and problems, many are very applicable outside as well.

Here are a few to get you started:

  • 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.
  • Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
  • Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.
  • Mistakes are all right, but failure is not. Failure is just 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.
  • 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.
  • 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 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.
  • Reviews, meetings, and reality have little in common.
  • 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 modern 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.
  • People who monitor work and don’t help get it done, never seem to know exactly what is going on.
  • 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 is made as a result of this discussion.
  • 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.
  • Integrity means your subordinates trust you.
  • There are rare times when only one man can 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.
  • 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.
  • A person’s time is very important. You must be careful as a manager that you realize the value of other people’s time; i.e., work you hand out and meetings should be necessary. You must, where possible, shield your staff from unnecessary work; i.e., some requests should be ignored or a refusal sent to the requester.
  • The project manager who is the smartest man on his project has done a lousy job of recruitment.
  • Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.
  • The boss may not know how to do the work, but he has to know what he wants. The boss had better find out what he expects and wants, if he doesn’t know. A blind leader tends to go in circles.
  • In political decisions, do not look for logic– look for politics.
  • Too many people at Headquarters 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.

Monorepos: Please don’t!

I have only recently discovered the concept of monorepos. It does sound interesting and I am yet to try it out, or, at least, dig deeper into the subject. But then, there are people who have strong opinions against them, and I the reasoning makes all the sense to me. Here’s a nice one: Monorepos: Please don’t!

sr.ht (“sir hat”) – open source software suite for managing your software development projects


sr.ht – pronounced “sir hat” – is a new competitor in the world of GitHub, BitBucket, and GitLab.  Much like all of these, you can either self-hosted it or use a managed service.  It might not yet be as fancy, polished, and cool (I think they need a better name and the domain) as its competitors, but there are a couple of reasons that might make a difference when making a choice:

  1. Open Source.  From a quick look, sr.ht is distributed under the GNU Afero GPL.
  2. Modular.  The suite consists of the following components:
    1. git – git repository hosting service
    2. build – continuous integration service
    3. lists – mailing lists service
    4. todo – ticketing system / bug tracker
    5. dispatch – task dispatcher and integration service
    6. man – markdown and git-based wiki service
    7. meta – account management service

 

Go Monorepo


As a maintainer and contributor to multiple, and often related, git repositories, I often find myself thinking that there must be a simpler way.

Consider, for example, a variety of CakePHP plugins that we develop and maintain at work.  Sure, each one provides a completely separate bit of functionality and has its purpose as a standalone project.  But, at the same time, they all have enough overlap that we use a common cakephp-plugin-template repository to keep things in sync, and also require cakephp-utils plugin from all of them.

It’s only natural to consider other ways of doing things.  Sure, I tried git submodules before, but they don’t quite cut it.  Something is still missing.

Today I came across the Go Monorepo website.  Which makes me wonder even further down this road.  There are also a few other tools and alternatives mentioned in this article.

That’s not something that I’ll jump into right now, but it’s definitely something I’ll consider to try out in the nearest future.

The Tool that Will Help You Choose Better Product Ideas


Itamar Gilad, of ex-Google fame, has an excellent post – The Tool that Will Help You Choose Better Product Ideas – which describes a process for selecting better product ideas and implementing them with confidence, minimizing the risks and maximizing the team efficiency.

Unlike many other similar posts, this one is very practical, detailed, and relies on iterations, feedback, communications, and ties together different roles within the company or the team.