Re: Space Access Update #112 9/19/05

Tom Cuddihy wrote:
> Len wrote:
> > Dr John Stockton wrote:
> > > JRS: In article <ti92m1t86lp51j6pvnsdpoek1cb38pgv08@xxxxxxx>, dated
> > > Thu, 27 Oct 2005 19:39:14, seen in news:sci.space.policy, Monte Davis
> > > <monte.davis@xxxxxxxxxxx> posted :
> > > >
> > > >Without such a loan, though, the challenge is to find an economically
> > > >viable path *from* where we are today *to* the promised land of CATS.
> > > >It's a tough challenge that's almost certainly going to require a long
> > > >series of incremental nibbles at the problem from technology AND
> > > >politics AND alt.space entrepreneurial economics... not a "silver
> > > >bullet" breakthrough from any one angle.
> > >
> > > That is why it is wrong to concentrate on designing (which in this field
> > > means "not very expensive") to do cheaply such as : orbit loads of
> > > tourists; supply ISS; launch satellites; launch interplanetary vehicles
> > > or components.
> > >
> > > Instead, the aim should be primarily, by showing the design, to get
> > > enough money to develop, build, and launch it, and secondarily that its
> > > success should advance the cause of affordable access in some way or
> > > another. If the first is achieved, the second is near-inevitable.
> >
> > While I generally agree that the main path should be
> > going for the money, one should not dismiss easily the
> > importance of conceptual design early in the game. This
> > is true for two reasons: 1) A good design may--not always
> > --help get the money; 2) Once serious money starts to be
> > spent, then all opportunity for thinking on the conceptual
> > level is gone; all effort then goes into detail design of
> > the existing concept, right or wrong.
> >
> > This is one of the things that has gone so wrong with
> > procurement. There used to be far more opportunity for
> > relatively free-structured exploratory study. Now the
> > emphasis is on total package procurement, without ever
> > figuring out a basically good approach. What passes for
> > exploratory study these days tends to be limited to someone's
> > preconceived notion of a good approach to a basic need or
> > problem--rather than a wide-open investigation of the basic
> > need itself (contrary to OMB A-109).
>
> I don't know, from my perspective it is actually an overemphasis on
> studies and requirements justification that has resulted in a
> excessively long, underwhelmingly successful process.

......

I guess I didn't state my case well enough, since we seem
to be on the same side of this argument. I agree that
there has been an overemphasis on requirements justification
--and, I might add, on the *method* for arriving at a good
concept, rather than the quality of the concept itself. As
far as I am concerned, if someone can come up with a really
good concept that stands up under rigorous analysyis and meets
a real need, stated or not stated, then I really don't care
how that someone managed to come up with the concept.

>The exploratory
> studies that tend to focus on long-range technology forecasts and
> 'stretch' requirements result in overblown, underbudgeted requirements
> that end up being undoable. Witness FIA. Witness SBIRS low. SBIRS high.
> Advanced Wideband Commuications Architechture. Joint Tactical Radio
> System. Other unmitigated disasters are in the making, I guarantee.
> The hits go on. What they all have in common is that they followed a
> rigorous, careful 'study and analysis' process, which focused on trying
> to carefully decide the exact right way to do things, then justifying
> it, etc--still to find themselves horribly unrealistic with regard to
> estimating what could be accomplished and how much it would cost.
>
> I think what it tends to come down to in the end is two things--first
> an arrogance that you can somehow predict the future. We build these
> systems that are going to take 10 years to get into orbit. Knowing
> anything we start building today will be obsolete by that time, we
> build in upgrade periods DURING THE DESIGN PROCESS, or we insist on
> requirements that we're not sure we'll be able to meet, based on some
> loose parametric analysis of technology trends. This is usually at the
> technical level, where we say 'we know we can't do X today on orbit,
> but given current trends, we will be able to do that on orbit before we
> get to that point in the program...' Then when our technology falls
> short of expectations, we have to scramble to provide a tenth of what
> we intended to do. By the same token, sudden upgrades often cause
> programs to veer well into the building process, which causes even more
> delays and increases in cost.

The most neglected and poorly supported concepts are the
ones that do not require any new technology--just better
design. The government gets quite excited about ideas that
improve current systems a few percent, or about systems that
depend upon questionable, exotic technology that take the
10 years or more that you mention. However, there tend to
be no doors to knock on, when it comes to ideas that can
revolutionize the way of doing business, just by putting
together things we already know how to do into a better overall
system. Years ago, one government agency with only five or six
people on its staff managed to come up with: 1) recoverable
capsules from the first intelligence satellites; 2) the U-2;
3) the A-11/A-12; 4) Glomar Explorer; etc.--all on rather
tightly controlled, well-managed, modest budget. But none of
these programs were based upon unobtainium; nor did they
take more than about three years. The mainstream bureuacracy
could not tolerate such a group, and they were eventually
cut down to size.

> The second thing we tend to do, even as we assume we'll have have
> nearly obsolete satellites even before we launch them, is we somehow
> think by understanding this concept, we can therefore ignore the
> reality of that fact. This is what causes us o overreach with
> requirements. Since we don't know how to do what we want to do, we just
> make it a 'requirement' to do what we want to do, as if this will
> magically make the solution feasible economically or technically.
>
> What we need in the government is 'reality based requirements,' an
> understanding from the beginning of the conceptual process that every
> requirement has a technically feasible corollory. The only way to do
> this is to limit the design-to-fly time to a period of under 5 years.
> Anything longer, the technology is obsolete by the time you launch it.
> Anything that length or less, even if it doesn't work exactly the way
> you envisioned it, at least you can launch an upgraded replacement
> before going too much longer.

I think that a better way of saying this would be 'reality
based technology' for most, not all, projects. I
actually feel that the requirements process is too much
bound by the perception of what is capable, because the
group stating the requirement does not want to appear
silly. Accordingly, I think two levels of requirements
might be appropriate. The first level would be tempered
by what people think is possible (or real). However,
another level might allow for capabilities that may be
quickly within reach, although not currently foreseen as
realistic.

Best regards,
Len (Cormier)
PanAero, Inc.
x@xxxxxxxxxxxxxx (change x to len)
http://www.tour2space.com
>
> tom

.

Relevant Pages

  • Re: Space Access Update #112 9/19/05
    ... >>>series of incremental nibbles at the problem from technology AND ... >> enough money to develop, build, and launch it, and secondarily that its ... > importance of conceptual design early in the game. ... build in upgrade periods DURING THE DESIGN PROCESS, ...
    (sci.space.policy)
  • Re: NASA Space Shuttle - The Real Problem
    ... Saying the "shuttle runs on old obsolete technology" is a red herring and should be labeled as such. ... A launch of December 2006 means the hardware has to be delivered to Kennedy Space Center by June 2006. ... That means the prototype initated tests around June 2004, so the tests can be run and evaluated in time to start construction of the flight unit. ... *no significant design changes after the breadboard*. ...
    (sci.physics)
  • Re:Urgent requirement for Java developers.
    ... Identifies key business and technology drivers that impact application ... and application design, coding and design standards, best practices, ... application of techniques and standards such as service-oriented ... Expert level on Java J2EEdevelopment knowledge (5+ years on J2EE ...
    (comp.lang.java.beans)
  • Re: staging, reliability, etc. (was Re: Towed Booster Stability)
    ... One D III failure was due to poor judgement by the company in not expending ... of the first flight. ... They appear to now have a mature design and operation. ... But launch ...
    (sci.space.policy)
  • Re: Size of the proposed "new" space vehicle?
    ... Try looking at the X-33 program and tell us ... >> exactly where X-33 had some serious problems. ... > technology, crew adaptability to space, and general space engineering. ... Add a vacuum bottle design, ...
    (sci.space.shuttle)