Now that you have heard the first case study, you have your first homework
assignment, and it's due next week!

Experience shows that you are probably a LITTLE bit confused about how to
accomplish the homework, and a LOT concerned about the difficulty of the
assignment.

Not to worry!  This first case study is an example, and although the case
is convoluted and messy, it really is an easy one to analyze.  And, since
this is a "practice" case study, I always ease up on the grading. So, don't
worry!  (I know, I know... you're thinking that's easy for HIM to say!)

First, let's look at WHY there are FIVE political Facts Of Life.  The entire
class can be distilled down to the simple equation "MONEY = POLITICS".
But the purpose of the class is to equip you with an understanding of the
political process, and the various ways that it can (and will!) impact your
design.  This class describes FIVE different major ways that this can happen.
All of them are interrelated, and all are merely specific instances of
"MONEY = POLITICS".  So it should be no surprise that some things in the
case study exhibit several of the Facts Of Life in operation.  Which of
the five is often entirely dependent on how you present it.  And this
characteristic is likely to cause confusion at first.

Let's look once again at the five primary Facts Of Life, this time in terms
of HOW each one impacts system architectures and designs, and in terms of
the symptoms that characterize each one of them.

#1:  POLITICS, NOT TECHNOLOGY, CONTROLS WHAT TECHNOLOGY IS ALLOWED TO ACHIEVE
Symptoms:  Project needs certain resources (budget, schedule, approvals)
but the political system often provides insufficient resources or imposes
constraints that force the project to change its design.  And sometimes
the opposite political effect occurs-- the political system places demands
(usually in terms of schedule) that challenges apparent technological limits
and forces the project to a non-optimal solution.

#2:  COST RULES
Symptoms:  Project needs a large budget, which if bluntly presented to
the political system would result in outright cancellation of the program.
The program instead tries to keep the program alive by presenting it in
the best possible light, i.e. overstating the benefits and understating
the costs or risks.  The program is forced to adjust its design or stretch
its schedule just to get the budget approved.  Or, the program is forced to
present overly optimistic assumptions in obtaining the program's budget.
Or, the program is told that the total budget for the budget area is fixed,
and another program in the budget area would have to be cut in order to
transfer funding: a "zero-sum game".  Or, the program is awarded a small
budget for the forthcoming year (often with a promise of more funding in
the out-years) which stretches out the schedule and significantly increases
the total program cost.  In short, a big budget makes for a big political
target.

#3: A STRONG, COHERENT CONSTITUENCY IS ESSENTIAL
Symptoms:  Project needs supporters in order to get (or keep!) its budget.
This support has to be very strong to overcome opposition, usually so
strong that no single group has sufficient strength.  Consequently an
often-fragile coalition of supporters must be formed, which somehow must
be kept together year after year to keep the program sold.  Altogether too
often, internal strife from conflicting agendas fragments the constituency
unless it is coaxed into a laser-like focus on a single agenda-- namely
supporting the program.

#4: TECHNICAL PROBLEMS BECOME POLITICAL PROBLEMS
Symptoms:  Project has several engineering challenges, which is normal.
But some of these problems are "blown out of proportion" and presented
to the political system as ammunition against the program, often by an
opposing side that want the funding redirected to themselves.

#5: THE BEST TECHNICAL SOLUTION IS NOT NECESSARY THE BEST POLITICAL SOLUTION
Symptoms:  Project has several options, all of which can be satisfied with
the available resources (this is what distinguishes it from Fact Of Life #1).
The technical community examines the requirements, develops evaluation
criteria, and chooses a preferred technical option based on the logic of
good Systems Engineering.  The political process often chooses a different
option, which best suits the political reasoning process (negotiation,
compromise, and appearance).  Much to the frustration of the technical
community, the preferred political solution (which may be to "do nothing"
or defer the decision for a year) often appears to be illogical, and can
even be the most expensive of the options!

So, how do you answer Fact Of Life #1:  POLITICS, NOT TECHNOLOGY, CONTROLS
WHAT TECHNOLOGY IS ALLOWED TO ACHIEVE?

Just look at the case study and ask yourself: "Were there any technological
limits? What were they? Did the political process place constraints that were
even tighter than the technological limits? (Usually in the area of BUDGETS
or REGULATORY APPROVAL or SCHEDULE.)  Did the political process cut back
resources necessary to accomplish the project, and thus force a project
re-plan (or choice of an alternate plan because of the insufficient resources)?
Did the political process challenge the project to accomplish something
according to a seemingly-impossible schedule?

So, you would write down a bullet or sentence that showed a specific
technology goal. Then you would show the corresponding political constraint
(or challenge), including a description to show that the political constraint
was more limiting (or challenging) than the technology goal.

Do the same sort of thing for Fact Of Life #2:  COST RULES. How did big
budget requests come into play, and how did they shape the decision-making
process?  Did the political process "believe" the program's initial cost
estimates?  Did the budgetary process ever come back with a smaller,
politically-motivated number?

In future case studies you'll want to look for the following in answering
Fact Of Life #2: COST RULES... were dollars allocated on the basis of political
expediency rather than cost efficiency?  Was funding restricted because of
governmental cash flow conditions (i.e. we can only afford this small amount
this year) which resulted in project schedule slips and delayed functionality?
Did somebody have to overstate the benefits and underestimate the costs, just
to get the program started?  Did any of this result in program stretch-outs
that drove up unit costs and total program costs?

And, you do the same for Facts Of Life #3, #4, and #5. For Fact Of Life #3:
A STRONG, COHERENT CONSTITUENCY IS ESSENTIAL... where did a strong constituency
help to keep the program sold?  Or, where did a weak constituency fail to
rescue program funding?  How "solid" was the constituency, and were there any
problems with factions or internal rivalries?

For Fact Of Life #4: TECHNICAL PROBLEMS BECOME POLITICAL PROBLEMS... were
there any technical problems (or the "appearance" of technical problems)?
Were there any political ramifications/repercussions?  By the way, it's OK
if two DIFFERENT technical problems have the SAME political response (hint-hint).

For Fact Of Life #5: THE BEST TECHNICAL SOLUTION IS NOT NECESSARY THE BEST
POLITICAL SOLUTION... this one is harder-- don't confuse it with #1. Look
for cases where there are two or more options, and there are sufficient
resources to support any one of the options (this is what makes it different
than the other Facts Of Life).  Were there any cases where the technical
community came up with a different "best choice" than the political community,
even though both groups had the same facts?  Did the political system ever
choose an apparently stupid idea (from an engineering or technical perspective)?
Did the technical community propose ideas that were technically possible but
politically unacceptable?

Remember that you will need to do TWO DIFFERENT bullets for each of the above,
plus ONE BULLET for one of the "Additional Facts Of Life", such as... hmmmm...
let me think... oh, say, "Timing Is Everything" just as an example
(hint-hint-hint). What was an example where the timing of a finding or of
a decision did (or did not!) influence the technological choice?

IMPORTANT:  Each bullet need not be a complete sentence, but you must provide
sufficient EVIDENCE from the Case Study to support your point.  You will lose
points if you don't provide supporting evidence!  For example, in response to
Fact of Life #2:
   * (bad) Project cost $2B, which is a lot of money, and Cost Rules.
   * (good) Project cost of $2B was originally presented to Congress by NASA
     and set a political "maximum"-- all counter proposals (such as the $1.5B
     by TX & AL Members of Congress) had to be less than this benchmark figure.

IMPORTANT:  To obtain full credit for your homework, you need at least
ELEVEN different bullets-- two each for Facts of Life #1 through #5, and one
for any one of the so-called Additional Facts of Life.  Your score will be
lowered by one point for each missing bullet! Also remember that if you
propose a "new" Fact of Life, and provide a bullet that shows how it applied
in the case study, then you can GAIN ONE POINT of EXTRA CREDIT!

I've worded the sample case study such that it contains keywords that "hint"
which of the Facts Of Life come into play.

In past classes, some students found it helpful to create a TEMPLATE document
with each of the five Primary Facts of Life and all of the Additional Facts of
Life.  They would print out a blank copy of the template before each lecture.
As the lecture unfolded, they would jot down a keyword (or page number) next
to the appropriate Fact of Life on their template.  To complete their homework,
they'd simply expound on their notes.

Bottom line-- fear not!  And if you have trouble with this assignment, give
me a call or send an e-mail message, and I'll gladly help you out.