Hi, Steve!
On 12/2/2013 9:11 PM, Steve Newcomb wrote:
> Tom, I'm trying to understand how to act on your excellent observation.
>
> I think I'd put it a bit differently. I think the fatal flaw in
> government contracting, as I have frequently experienced it, is very
> simple indeed. It takes three things for anyone to succeed in any project:
>
> (1) Responsibility for making it work.
>
> (2) Authority for making it work.
>
> (3) Ability to make it work.
>
> In my experience, these three essentials are almost never left in the
> same hands, and their separation from each other is the reason for
> failure. Putting them all in the same same hands may not work, but
> separating them will surely not work.
It's not just the government, though. If you follow The Daily WTF site
for a while, you'll see that non-government companies can be just as bad.
I can give you a more concrete example of the separation of these three
activities. Take an hardware item destined to go into a submarine. I -
my company at the time - have built such items, reactor related things
for nuclear subs. If you or I go to the hardware store and buy a tool,
but it doesn't do what it's supposed to, we find out quickly and usually
can return it. But for our submarine item, even if there is an existing
supply contract (and there usually is), the contract and specification
were written and the item developed and qualified by (or for) one
agency. The procurement may have been done by another. The item is
shipped to and stored by yet another organization. Finally, perhaps
many years later, the item is requisitioned and delivered to a ship,
whose personnel have to use it. And, for our sub, it has to work. They
can't take it back, and they can't rework it.
And, for our subs at least, all such items by and large do work - we
know because the subs sail, and the reactors don't blow up or melt. But
I will tell you that none of it worked right the first time.
It's not the government's fault, but that item *cannot* be procured,
developed, tested, qualified, and used all by the same people or
organization. The areas of expertise are too diverse, and the span of
time between development and use is too large.
Well, here we're mostly talking about software systems, but it's not
that different in this regard. So we *want* to have things work as if
developed and used by the same person or organization, who as you say,
can take responsibility and have a personal stake in the outcome. But
we can't. The name of the game, then, is to invent ways to come as
close as possible to the ideal.
Now, it's certainly the case that the government (whichever one it is,
not just the Federal government of the US) can mess up each and every
level we've pointed out above. And it often does. That only makes
things worse.
Back to the submarine example, we came close to your ideal, as close as
we could anyway, when Rickover developed the nuclear submarine. *He*
was the one in charge, he had the authority and the backing, and
apparently he had good managerial skills. And every Tuesday without
fail we and every nuclear contractor had to send a letter addressed to
him *personally* that would begin
"Dear Admiral Rickover: The following items are critical to the
development of XXX:"
If there were no critical items, you had to write "None". Otherwise you
had to state the critical item or items, it's expected delay, what has
changed from the last letter, and who was responsible in the government
for making it happen.
This letter was a contractual requirement. (As an aside, at first the
letter had to be addressed "Dear Vice Admiral Rickover". When he
finally got promoted, we were notified to change it to "Dear Admiral
Rickover").
Maybe this is the way to handle these complex, important systems. It
worked for Rickover. Or maybe this can only work when you have a truly
exceptional person like Rickover or Kelly Johnson.
