What software project managers can learn from NASA

Vintage advice from the space agency is applicable today to those building software

Water bottles that say My glass is always half full

NASA thinks these novelty water bottles reflect the mindset of engineers

Credit: flickr/EvelynGiggles

I think we can all agree that when it comes to building stuff, NASA has a long history of knowing what it’s doing. That doesn’t just apply to rockets and spaceships and cool hardware like that; NASA also has a pretty good track record of building high functioning and pretty reliable software. So, when NASA gives out advice on how to manage a project, we should all listen.

I bring this all up because I recently came across the list “A Project Manager’s Lessons Learned,” 128 rules compiled back in 1995 by Jerry Madden, Associate Director of the Flights Project Directorate at NASA’s Goddard Space Flight Center. The list, apparently, has been in the public domain for some time, but this was the first that I’d seen it. After taking a spin through all of the rules, I thought that a number of them would certainly still apply today, particularly for software project managers.

For example, the following rules seem like good, solid generic advice for project managers that can all apply to software development:

Rule 90: The seeds of problems are laid down early. Initial planning is the most vital part of a project.

Rule 54: 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.

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

Just a couple of rules deal specifically with computers and software development but here’s one which still rings true (tl;dr: use source control):

Rule 77: 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.

Finally, my favorite rules are the ones that talk about dealing with people, particularly engineers (emphases are mine):

Rule 6: 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 make 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.

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

Rule 68: 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.

Engineers like puzzles! Well, I’d say that’s right on. Not sure that last one really applies to all software engineers, though. Born optimists? I don’t know about that.

Anyway, the whole set of rules is a fun read. If you haven’t seen it before, take a look and enjoy.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon