TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Robert I. Eachus" <[log in to unmask]>
Mon, 24 Mar 1997 15:48:14 -0500
text/plain (96 lines)
  Richard said:

  > It is the realization that this was a management failure that I find most
  > troubling.  If the professional managers in the DoD could not manage
  > something as simple as a single-language policy, how can we imagine they
  > will be able to manage a more complicated, multiple-language policy? And
  > these professional managers are some of the brightest, most dedicated
  > people I know.  Yet the single-language policy was beyond their ability
  > to manage.

  > Perhaps software policy, by its very nature, defies any attempt at
  > conforming to a coherent set of management policies.  Perhaps we
  > are so skilled in the technical issues related to software that we
  > are unable to rise to the challenge of the management issues.

   Let me weigh in again on this.  In the late eighteenth century
warfare became too complex for a single general to manage an entire
campaign.  Aide-de-camps evolved into staff officers, then into the
full formality of a general staff.  Since WWII, the speed and
complexity of maneuver warfare has reached a new level, and trying to
manage an air battle without decision support systems would be an
exercise in futility.  (Ask Saddam Hussein--or ask General Horner why
Iraqi command and control systems were given such priority.)

   Look at Cheyenne Mountain, and you will see billions of dollars
invested in a complex system whose sole purpose is to manage the
strategic defense of the United States and Canada.

   Now look at the people buying systems like ABCCC3, AWACS, J-Stars,
and Cheyenne Mountain Upgrade.  Where are their automated decision
support systems?  For that matter where are their paper decision
support systems, or even the TO&E for a general staff for acquisition

   Those tools don't exist.

   At MITRE we have made a start on, and are continuing to develop,
support tools for software and system architects.  These are useful
for letting the system architect see where the potential problems are
early enough to do some good.  But right now, those tools are futile.

   It doesn't help if the system architect can discover problems two
to three years in advance--in time to do something about them--if the
project manager is over his head in problems which must be dealt with
now.  So someone needs to start building a decision support system for
the procurement officials so they have enough time to listen to the
problems that are not of today, but can be solved at little or no cost
if dealt with now.

    Accounting systems don't count.  They deal with the past, and let
you know just how badly your project was doing six months ago.  Six
months ago you knew that, in fact you knew earlier that you were
headed for trouble.  But the tools that would tell you where to go to
stop the bleeding don't exist.

    I'll be much more explicit.  You have between DoD, FFRDCs, TEMS,
contractors, and subs hundreds, even thousands, of people working on a
project.  Assume I have available a perfect GANT or PERT chart tool to
tell me all the internal milestones and their status.  It lets me know
the minute any deadline on the project is missed, and suggests
corrective actions.  Such a tool would be no better than what we have
now.  What we need to know, and spend a lot of time finding are the
risk areas where projects can fail.  But what we need are the tools
that will let us look over the contractor's shoulder on those key
issues, and see not just whether they are ahead or behind
schedule--conceptual breakthoughs don't happen on any schedule--but
whether they have anyone competant to find a solution, and if he is
tasked to do so.  (Correction...and if that individual has time and
resources to devote to the problem.)

    I think that if we had a system which allowed the program manager
for the government and the project manager for the contractors to get
together and solve such issues while leaving the contractual and
financial issues to be resolved by staff, then we would have a
mechanism that led to success rather than disaster.

    There are contractors--I won't name any names to avoid
embarrassing those not mentioned--who seem to use this model
internally.  Now all we have to do is get a similar model in place on
the government side.  I have worked programs where the project
manager on the government side HAD to spend 100% of his time on
contractual, financial, managerial, and staffing issues.  The result
isn't pretty.

    To sum up, you know the project is in trouble when either the
contractor or government project manager gets called out of a design
review to deal with some other crisis.  I've been at two day design
reviews where the project managers looked more like jack-in-the-boxes.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...