…costs more than fast failure.
This is about defense, but it applies to space as well. NASA in particular suffers from paralysis by analysis, as demonstrated by how long and how much money it took to do that stupid Orion test flight last year (and how long and how much more money it will be until the next one). But it doesn’t matter, because Congress doesn’t really care if anything is accomplished as long as the jobs don’t go away. I may expand on this in the next edition of the book.
In specific cases it shouldn’t even be that difficult to quantify those costs especially if you can assume a constant rate of burn. However, even failure may have seeds of success.
It’s particularly irritating that contracts take so long to award when the contract being awarded is for a “risk reduction phase.” This is becoming an end it itself, and more and more results in risk being reduced all the way to zero by never actually producing anything. I suppose that could be considered a 100% success, since the “risk reduction phase” would have had a perfect result.
“Risk” refers to the probability of an outcome or event having an undesireable consequence or consequences. The word by itself has no meaning, and it’s impossible to be averse to “risk” as such and still be a living organism. But I’ve been in innumerable meetings where entire programs were brought to a halt by someone in a high enough position simply saying “There’s risk,” without ever having to say risk of what, and with what consequences. It is the new way to be smart without having any brains.
As with software, failure to properly identify requirements before beginning development is the cause of most procurement disasters. Failure to reign in “requirements creep” is another big factor. Projects get larded up with gold-plated “nice to haves” that do nothing except drive up the cost, weight, and likelihood of failure.
The only thing that stops creep is someone willing to say no or walk away. Doesn’t happen too often.
It happens often in the real world. We regularly trade off ‘nice to have’ requirements against schedule or budget.
It doesn’t in government, because they’re spending other people’s money and don’t care about results; in fact, they’ll use failure to justify a larger budget next year.
And for the contractors on a cost-plus contract, requirements changes and scope creep just mean more money, at least until the program gets killed. I’ve seen it happen so many times resulting in massive waste with nothing to show for it.
Early on, yes. But, once a project gets a head of steam, suddenly they realize they want more. If you’ve got management between you and the customer they will often make promises before speaking with the people that have to keep them, unless you train your bosses first.
Well, and the other problem is that sometimes the agency procuring the system isn’t the agency that plans to use it. Requirements end up not reflecting user needs until you get past PDR and the prime contractor’s “customer” (the procuring agency) actually briefs what they’re buying to the agency that plans to actually use the product. Uh oh! Time to go back to the prime with a revised spec…