|
||||||||||
|
|
When you build a cost model for a new development program, be careful of your initial assumptions. Costs always expand to fit the available budget. If you have enough money, you end up turning engineers in to bureaucrats who can find no end of new and creative ways to keep people busy doing things that are complete waste of time. |
|
Comparing Apples to Apples
Among the frequently raised objections to the business models for the Artemis Project is that the projected costs are only a small fraction of the cost of the Apollo program. If Apollo spent 40 billion dollars to get to the moon, the argument goes, how could a program named after His twin sister cost only a billion and a half?
Therein lies the blunder. If you want to build a parametric cost model, make sure your parameters make sense. If you aren't comparing apples to apples, you will end up with a huge budget for the program, and sure enough, your program will cost as much as you thought it would.
Building an engineering development cost model based on the Apollo era doesn't make any sense at all. The only commonality between the Apollo and Artemis programs is destination -- the moon -- and the fact that the programs were named after a pair of twins from ancient Greek mythology. (Apollo and Artemis were twins born to the goddess Leto. He is the sun; She is the moon.) Everything else is different.
When NASA developed the Apollo spacecraft, they were starting from scratch. They had to create everything: the launchers, the spacecraft, the entire body of knowledge about human performance in space and the lunar environment. They had to invent the engineering processes and even techniques for public relations. In the 1960's, the primary function of NASA was to defeat the Soviet Union by luring them into a race where the Soviets could not compete with the economic power of the United States -- the USA simply out-spent the Soviet Union in the race to the moon. None of these situations is applicable to the Artemis Project.
Perhaps the key difference between the Artemis Project and the Apollo Program is that the technology we use for engineering development so dramatically different today.
In the days of Gemini and Apollo programs, all but a minuscule fraction of the engineering hours were spent doing the drudge work. An anecdote told to me by engineers who worked on the Apollo program provides a poignant example.
Red Tape and Paper Tape
In the days of yore, McDonnell Douglas built an engineering simulator of the Gemini electrical system. Each Gemini spacecraft was a little different, so they had to make a math model of each ship, and keep the math model updated. That meant lots of changes.
The math models were stored on punched paper tape. (The hottest storage device around back then was the magnetic drum.) Engineers would work out the math model and fill out a form, and a team of keypunch operators would punch the tapes. They didn't have a way to duplicate or edit these tapes; to make a change, they had to start all over with a new tape, keypunching every bite by hand. When a tape was done, the operator would make a printout, and the engineers would painstakingly go through the whole thing looking for errors. If they found an error, the operator had to start all over again.
The great joyous moment for the electrical system simulator team was the day they finally convinced NASA to let them acquire a teletype machine that could not only punch paper tapes, but also duplicate them.
Extrapolate from that experience the amount of human effort that went into the function you perform today every time you smack that backspace key. In such an environment, labor costs soar.
The cost of a program is directly proportional to the amount of human effort required to accomplish it, so in the early 21st century we can reasonably expect that the development costs for new manned spacecraft will be a tiny fraction of the amount required to develop the first manned spacecraft.
|
|
|