ARO 420

Program Management
Block 1
Course Overview,
P.M. Fundamentals
Professor Dobbs
Aerospace Engineering
Cal Poly Pomona

Why take this course?

I cant be a Program Manager for years!

Alumni and Student Comments

on the Importance of ARO 420,
and ARO 201, for use in EGR
461, and ARO 482/492 and in
their careers
Prof. Steven Dobbs
Fall 2013

Recent Alumni comments

Hello, Prof. Dobbs. This is Anthony, one of your students last year who got a job
with the Missile Defense Agency in Huntsville, AL. So far, work is great. But
more importantly, I would say that out of the ARO instructors, you actually
prepared me the most. So far, I have been exposed to many Systems
Engineering and Management topics that you taught in your ARO 420 course and
what you emphasized to our Senior Project group when writing the report.
For
For the past 3 months, Ive been engulfed with systems engineering.
engineering It turns out
that one needs to perform all the systems engineering work prior to actually
procuring and building anything, SURPRISE!!! Thanks to your SE & EGR (Ethics)
class and Rays 499 class, I was more than prepared for this. I didnt realize how
valuable you can be when you can apply your engineering background and
technical writing to SE.
Two weeks ago I started my new job with NAVAIR in Store Separation and
Experimental Wind Tunnel Testing. Because I will be spending a lot of time in the
NAVAIR wind tunnel, my Free Mounties senior project was a huge selling point
during my interview. Not only did they like the wind tunnel experience,, they also
liked all the test procedures, pretests and analysis that were done before we ever
went into the wind tunnel.
tunnel
I wanted to say thank you for requiring us to go the extra mile for the [senior]
project. Had we simply thrown a model in the wind tunnel and tested it, I do not
believe my boss would have been as impressed. Not only did the project help
me get the job, it is also helping me as I work on wind tunnel projects as I am

Recent Alumni comments, cont

As I go off into the working world I must say thank you because I
owe a part of my career success to you. Thanks to you I have a
background in Aeroelasticity & Flutter and have learned so much
about Systems Engineering and Program Management.
Management

Initially, I had no idea how much of what I learned in college would

actually be used during my career.. I can honestly say that the class
that I have used the most so far is Systems Engineering.
Engineering It is a part of
every paper I read/send and every training I am required to attend.
Taking those classes has definitely improved my speed and ability to
perform my current tasks.
As you would recall, the graduate project was a land development
cost model for the algal biomass production industry. In the project I
applied principles of systems engineering that I learned in your
graduate class. Your guidance on this was greatly appreciated.

Student comments from ARO 420..

The
The management techniques in the class will be and have been directly
applied to the program I am managing [at work] that will be my biggest take
away: application.
I learned a lot from this class. I was able to hold a conversation with a high
level manager from SPAWAR about systems engineering because
everything we did in this class he does on his job.
job
I enjoyed performing presentations.
presentations Presentation 2 was the first time I was
comfortable [in] public speaking.
Being
Being a program manager taught me a lot of responsibility and how to lead
a team to successfully design and produce a quality report for our project.
This
This class was a great help in organizing for senior design. Also learned
about management and hopefully will understand what project leads have to
do.
the team leaders did more work than others in the class. This makes
sense, but I feel that sometimes group members dont understand what the
leader is actually required to do for the course. Maybe there is a way to
change leaders or add more group responsibility? Over all , though, I
learned a lot about SE and feel more prepared for senior design.
Overall good class but material is a little boring.
This class showed me that I never want to be in program management.

Week

Session Title

Study Assignments
Due by Next class session

Assignments
Due Next class session

Text: Eisner, H., Essentials of Project and Systems Engineering Management, 3rd Edition
1

a) P.M. Fundamentals
(Define P.M., Roles &
Functions, Unwritten Laws,
Typical P.M. Problems,
Systems Thinking)

Chapter 1 Systems ,
Project and Management

HW #1- (a) Elevator

Speech (individual, due
Week 1b); (b) Analysis of
Program Management
Failures of the Space
Shuttle Columbia Accident
(due Week 2a)

Chapter 2 - Overview of
Essentials

HW #2 Construct Program
Org Chart for RFP. Other
HW as assigned by the
instructor.

b) Your Team Project :

Program / Project Plan
2

a) Organizations &
Responsibilities
Personality tests
b) Assign Teams; The
Program Plan Life Cycle
a) QUIZ #1, Writing a
Management & Cost
Proposal, b) The Project
Plan - through Step 1-3, c)

Life Cycle Diagram

Banner, Chapter 3.9 &
Chapter 6.8 - Proposals

Chapter 3 - 3.1- 3.5

HW #3 - Problems 3.1,
3.2, 3.3; Other HW as
assigned by the instructor.

The Project Plan

Chapter 4 - 4.1- 4.3.2

-Step 2-through Step 6

The Project Plan (PERT,
IMS, EVMS, Data Base).
- through Step 9

HW #4 - Problem 4.1;
Other HW as assigned

Chapter 3 3.6 3.8

HW #5 - Problem 3.4, 3.5,

3.6, Plan Briefing #1

Chapter 7 7.3.8

WH #6 - Problem 7.5.
Start Writing Team Project

a) Quiz #2, Activity based

Cost estimating
Relationships
b) Team Project Plan
Briefing Requirements

Project Plan Presentation

#1,

Chapter 5 The Project

Manager and Leadership

HW #7 To be assigned
& Prepare Project Plan
Brief #2

Leadership

Chapter 6 Team Building

and Team Interactions

HW # 8 & Continue to
Prepare Project,Brief #2

Quiz #3, Project Plan

Presentation #2, Team
Building & P.M. Trends,

Chapter 12.4- P.M.

Trends

HW #9

Integrative Management

Review for Final

10

Chapter 14 Integrative
Management
Final Exam

Course Objectives
Equip the student with the fundamentals of Engineering Program
and Project Management with the oversight of systems engineering
processes with emphasis on application to the Aerospace Industry
Describe the roles, functions and skills of Engineering Program
Management in product development and program monitoring
Discuss the problems and solutions the Program Managers must
address
Describe Corporate and Government organizational management
structures
Develop Program Plan development skills
Prepare Plans for ARO 482/92 & ARO 483/93 Sr. Design Projects
Develop team organization and leadership skills
Develop presentation skills

Scoring & Grading

Scoring:
3 Quizzes
= 25 pts
Program Plan #1 presentation = 20 pts
Program Plan #2 Presentation = 20 pts
Assignments
= 10 pts
Final examination
= 25 pts
Extra Credit Team leaders + at discretion of instructor
Grading
90%<A<100%
80%<B<90%
60%<C<80%
Failing<60%

Introducing your instructor - Steven Dobbs

Project or Program
Cal Poly Pomona BS AE graduate 1970
Management related
Cal State University Long Beach MS ME 1979
Other Post grad classes USC
Various industry training at Rockwell and Boeing in Functional Management, Program Management,
Leadership, Marketing & product development, & Systems Engineering
36 years at Rockwell NAA and Boeing, with Canadair (Montreal & Mojave), Lockheed Skunk Works
(Burbank), German Duetch Aerospace (Ottobrun/Manching), German DLR (Gottingen), Northrop
Grumman (El Segundo) working on over 25 aerospace systems and technology development programs
- In Aerospace engineering: Ground & Flight Testing, Systems Engineering, Program Management
- Retired as Director Lunar and Planetary Exploration Technology Development
7 years part time instructor at Cal State Long Beach in MAE department
X-43
Orion
Married 36 years, 2 daughters, 2 grandsons
X-37 & XX-40

CLCL-600

SLI

B-1A
Aero CC-112

HiMAT
Sabreliner

B-1B

FSW

OE

X-31

AFW

JSF XX-32
JPATS

Shuttle

Technology
Dev.
Programs

Express

Lockheed/
Rockwell BB-2

NASP

ABL

Euro Fighter
Orbital

X-53 AAW

TPS
Lunar
Lander

Who are you and what are your

goals for Aerospace Engineering
and Program Management?
- Pair up and discuss

Homework due next meeting

1. Open the Personality Style Tests .pdf doc on
the H drive folder.
a. Take the Smiley Personality Style survey (do not
look at what you dis in ARO 201L!),
b. Take the Program Manager Attribute Self
Assessment test (do not look at what you dis in ARO
201L!)
c. Take the Meyersis your Briggs Personality style from the
test on the Web

d. Record the 3 results on the Attendance sheet next

time

2. Elevator Speech

What is Program Management?

Program Management is the process of managing multiple ongoing inter-dependent

projects.
An example would be that of designing, manufacturing and providing support
infrastructure for an aircraft manufacturer.
This requires hundreds, or even thousands, of separate projects. In an
organization or enterprise,
Program Management also reflects the emphasis on coordinating and prioritizing
resources across projects, departments, and entities to ensure that resource
contention is managed from a global focus.
Program management provides a layer above project management focusing on
selecting the best group of programs, defining them in terms of their constituent
projects and providing an infrastructure where projects can be run successfully
As a discipline, project management developed from different fields of application
including construction, engineering, and defense. In the United States, the forefather
of project management is Henry Gantt, called the father of planning and control
techniques, who is famously known for his use of the Gantt chart as a project
management tool, for being an associate of Frederick Winslow Taylor's theories of
scientific management[1], and for his study of the work and management of Navy
ship building. His work is the forerunner to many modern project management tools
including the work breakdown structure (WBS) and resource allocation.
Program and Project Management must be integrated with Systems Engineering
Processes
This class will cover the principles of both Program and Project management

Hierarchy Levels of Management

Organizations
Enterprise Level
Architecture Level Level
Program or System Level

Project Level
Escape
Tower

Crew
Module

Service
Module

NASA HQ

Why is Effective Program Management Essential

for Program Success?
Longer development
times increase
probability of
cancellation!

140 No of Months

Army
100
Navy

80
60

Air Force

40

Schedule
slips drive up
cost!

1997

1995

1993

1991

1989

1987

1985

1983

1981

1979

1977

1975

1973

1971

Program Development time is increasing!

20
1969

Program Start to IOC

120

X-33
(Composite LH2
tanks, aft C.G.)

Overly risky technology

decisions kill program
viability and cost

NAVY AA-12
(composites & radar)

Department of Defense Schedule

Delays as of Jan 2009

Program Management Functions

PLANNING Establish Goals and Processes

ORGANIZING Assign activities to best use resources
STAFFING Select the right people
MOTIVATING Get the best from the people
COMMUNICATING Promote allegiance to a common
goal
MEASURING Compare performance with goals
CORRECTING Close the gap between the
performance and the goals

Roles of the Engineering Manager

LEADER Gets others to do things

FIGUREHEAD Represents the team
LIASON Coordinates with other teams
DISSEMINATOR Passes the information down
SPOKESPERSON Passes the information up
CHANGE AGENT Initiates adaptation
DISTURBANCE HANDLER Arbitrates disputes
RESOURCE ALLOCATOR Personnel, budget,
facilities, material
NEGOTIATOR Outward and inward

What are the Key Problems that Program

Management Must Overcome?
Activity: Table Discussion & Report on Flip Chart
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

What are some ways the program management

can overcome Key Problems?
Activity: Choose two of the problems and propose a solution
Table Discussion & Report on Flip Chart

Problem
1.

Solution (use Eisner Text list for help..)

1.
2.
3.

2.

4.
5.
6.
7.

3.

8.
9.

4.

10.
11.
12.

ARO 420
Unwritten Laws of Engineering Management
Approach to Addressing the P.M. Challenges:
The Systems Approach
Case Study Program Management Failures of
the Space Shuttle Columbia Accident
Planning for Your Team Project:
Program Plan for the Life Cycle of ___________

Unwritten Laws of Engineering Management

MANAGING ENGINEERING IS DIFFERENT
Activities are One-Time rather than repetitive.
Personnel are highly educated, well paid, mobile
Time is a major performance parameter.

Outcomes are not entirely predictable.

Costs are not entirely predictable

Resource costs are very high: Manpower, FacilitL

Control can stifle creativity.
The degree of success is hard to evaluate.

Unwritten Laws of Engineering

WORK HABITS
Give every task your best effort
There is a premium on getting things done
Keep track of others contributing to your project
Avoid verbal instructions
Stay on the job" until it is finished
Avoid the very appearance of vacillation

Don't be timid - express yourself and promote your ideas

Finish the planning before requesting approval

Communicate clearly and concisely

Be extremely careful of the accuracy of your statements

Unwritten Laws of Engineering

INTERACTIONS WITH THE SUPERVISOR
Keep the boss informed.
Remember who you work for.
Be loyal, Choose your boss very carefully.
Whatever the boss wants takes top priority.
Don't be a yes man".

Unwritten Laws of Engineering

INTERACTIONS WITH THE SUPERVISOR
Keep the boss informed.
Remember who you work for.
Be loyal, Choose your boss very carefully.
Whatever the boss wants takes top priority.
Don't be a yes man".

Unwritten Laws of Engineering

INTERACTIONS WITH ASSOCIATES
Never invade someone else's domain without
permission,
"Deal in" everyone who has a right to be involved
Be careful about distributing emails with negative
comments!
Provide time, cost, and performance projections when
requested.
Complain first to the individual responsible.
Remember that, to an outsider, you are the company

Approach to Addressing the P.M.

Challenges: The Systems Approach
Recognition that all elements of a system are related and
must operate harmoniously
Requires a systematic and repeatable process for
designing, developing, testing, and operating the system
No one element is designed without considering its
impact on the capabilities and characteristics on all the
other elements; avoids chimney design culture
Ensures that the Architecture of the system meets all
stake-holder requirements
Program Management should plan and execute the
program for all life cycle phases under systems
engineering guided processes

ARO 201 Redo Activity - System

Life-Cycle Engineering

Para #1

Para #2

Para #4
Para #3

HW#1 - System LifeLife-Cycle Engineering Article Key Ideas

(elevator speech)

Name ________________________

Para #1
Para #2

Para #3

Para #4 -

Date _______________ ARO 420 - __

Activity (start in class then finish in

homework Assignment #1)

Case Study Program Management Failures

of the Space Shuttle Columbia Accident
Background Technical Cause and the
Failure
What were the key five organizational
problems that contributed to the failure?
Who was involved or caused these
problems?
What was the impact of the problem on the
accident?
What could have been done by the Program
Management to prevent the problems?

This cause of exploration and discovery is not an option we choose; it is a desire written in the human heart
We find the best among us, send them forth into unmapped darkness, and pray they will return.
They go in peace for all mankind, and all mankind is in their debt.
President George W. Bush, February 4, 2003

Columbia
Accident 2003

Activity, cont. - SS Columbia Background Accident Technical Causes

Foam trajectory

Columbia Accident Investigation Board Report. Pg. 9

The physical cause of the loss of Columbia and

its crew was a breach in the Thermal Protection
System on the leading edge of the left wing,
caused by a piece of insulating foam which
separated from the left bipod ramp section of the
External Tank at 81.7 seconds after launch, and
struck the wing in the vicinity of the lower half of
Reinforced Carbon-Carbon panel number 8.
During re-entry this breach in the Thermal
Protection System allowed superheated air to
penetrate through the leading edge insulation and
progressively melt the aluminum structure of the
left wing, resulting in a weakening of the structure
until increasing aerodynamic forces caused loss of
control, failure of the wing, and break-up of the
Orbiter.
This breakup occurred in a flight regime in which,
given the current design of the Orbiter, there was
no possibility for the crew to survive.

Activity Assignment
Break up into teams of 4 or 5 and choose a
leader
Your team is assigned one of the 5 following
organizational problems that the Columbia
Accident Investigation Board identified as
contributors to the accident
Fill out the Power Point blank table chart with
your analysis and recommended solutions, one
chart per problem
Each team chooses someone to present the
chart to the class next session
Aim for 3 to 5 minutes per chart briefing

Activity, cont. - SS Columbia

Accident - Organizational Causes
Columbia Accident Investigation Board Report. Pg. 9
The organizational causes of this accident are rooted in
the Space Shuttle Programs history and culture, ...
Cultural traits and organizational practices detrimental to
safety were allowed to develop, including: Lack of
Commitment to a Safety Culture, reliance on past
success as a substitute for sound engineering practices
(such as testing to understand why systems were not
performing in accordance with requirements);
organizational barriers that prevented effective
communication of critical safety information and stifled
professional differences of opinion; lack of integrated
management across program elements; and the
evolution of an informal chain of command and decisionmaking processes that operated outside the
organizations rules.

Detail Causes 1. Lack of Commitment to a

Safety Culture
NASAs safety culture has become reactive, complacent, and dominated by unjustified optimism. Over
time, slowly and unintentionally, independent checks and balances intended to increase safety
have been eroded in favor of detailed processes that produce massive amounts of data and
unwarranted consensus, but little effective communicationpressures on the Shuttle Program.
Certain mechanisms may impede worker anonymity in reporting safety concerns.
NASA does not have a truly independent safety function with the authority to halt the progress of a
critical mission element.
Complex organizations need specific mechanisms to maintain their commitment to safety and assist
their understanding of how complex interactions can make organizations accident-prone.
Organizations cannot put blind faith into redundant warning systems because they inherently
create more complexity, and this complexity in turn often produces unintended system interactions
that can lead to failure. The Human Space Flight Program must realize that additional protective
layers are not always the best choice. The Program must also remain sensitive to the fact that
despite its best intentions, managers, engineers, safety professionals, and other employees, can,
when confronted with extraordinary demands, act in counterproductive ways.
Safety and Mission Assurance organizations supporting the Shuttle Program are largely dependent
upon the Program for funding, which hampers their status as independent advisors.
Senior Safety, Reliability & Quality Assurance and element managers do not use the Lessons Learned
Information System when making decisions. NASA subsequently does not have a constructive
program to use past lessons to educate engineers, managers, astronauts, or safety personnel.
Organizations with strong safety cultures generally acknowledge that a leaders best response to
unanimous consent is to play devils advocate and encourage an exhaustive debate. Mission
Management Team leaders failed to seek out such minority opinions. Imagine the difference if any
Shuttle manager had simply asked, Prove to me that Columbia has not been harmed.

Detail Causes 2. Reliance on past success as a

substitute for sound engineering practices
Conditioned by Success: Even after it was clear from the launch videos that foam had struck the
Orbiter in a manner never before seen, Space Shuttle Program managers were not unduly
alarmed. They could not imagine why anyone would want a photo of something that could be fixed
after landing. More importantly, learned attitudes about foam strikes diminished managements
wariness of their danger. The Shuttle Program turned the experience of failure into the memory of
success.18 Managers also failed to develop simple contingency plans for a re-entry emergency.
They were convinced, without study, that nothing could be done about such an emergency. The
intellectual curiosity and skepticism that a solid safety culture requires was almost entirely absent.
Shuttle managers did not embrace safety-conscious attitudes. Instead, their attitudes were shaped
and reinforced by an organization that, in this instance, was incapable of stepping back and
gauging its biases. Bureaucracy and process trumped thoroughness and reason.
Significance of Redundancy: The Human Space Flight Program has compromised the many
redundant processes, checks, and balances that should identify and correct small errors.
Redundant systems essential to every high-risk enterprise have fallen victim to bureaucratic
efficiency. Years of workforce reductions and outsourcing have culled from NASAs workforce the
layers of experience and hands-on systems knowledge that once provided a capacity for safety
oversight. Safety and Mission Assurance personnel have been eliminated, careers in safety have
lost organizational prestige, and the Program now decides on its own how much safety and
engineering oversight it needs. Aiming to align its inspection regime with the International
Organization for Standardization 9000/9001 protocol, commonly used in industrial environments
environments very different than the Shuttle Program the Human Space Flight Program shifted
from a comprehensive oversight inspection process to a more limited insight process, cutting
mandatory inspection points by more than half and leaving even fewer workers to make second
or third Shuttle systems checks
Over the last two decades, little to no progress has been made toward attaining integrated,
independent, and detailed analyses of risk to the Space Shuttle system.
The Space Shuttle Program has a wealth of data tucked away in multiple databases without a
convenient way to integrate and use the data for management, engineering, or safety decisions.

Detail Causes 3. Lack of clear communication

Program managers, from Ron Dittemore to individual Mission Management Team members,
had, over the course of the Space Shuttle Program, gradually become inured to External
Tank foam losses and on a fundamental level did not believe foam striking the vehicle
posed a critical threat to the Orbiter. In particular, Shuttle managers exhibited a belief that
RCC panels are impervious to foam impacts. Even after seeing the video of Columbias
debris impact, learning estimates of the size and location of the strike, and noting that a
foam strike with sufficient kinetic energy could cause Thermal Protection System damage,
managements level of concern did not changeIn the face of Mission managers low level
of concern and desire to get on with the mission, Debris Assessment Team members had
to prove unequivocally that a safety-of-flight issue existed before Shuttle Program
management would move to obtain images of the left wing. The engineers found
themselves in the unusual position of having to prove that the situation was unsafe a
reversal of the usual requirement to prove that a situation is safe.
A tile expert told managers during frequent consultations that strike damage was only a
maintenance-level concern and that on-orbit imaging of potential wing damage was not
necessary. Mission management welcomed this opinion and sought no others. This
constant reinforcement of managers pre-existing beliefs added another block to the wall
between decision makers and concerned engineers. Communication did not flow
effectively up to or down from Program managers. As it became clear during the mission
that managers were not as concerned as others about the danger of the foam strike, the
ability of engineers to challenge those beliefs greatly diminished. Managers tendency to
accept opinions that agree with their own dams the flow of effective communications.
Further, when asked by investigators why they were not more vocal about their concerns,
Debris Assessment Team members opined that by raising contrary points of view about
Shuttle mission safety, they would be singled out for possible ridicule by their peers and
managers.
Risk information and data from hazard analyses are not communicated effectively to the risk
assessment and mission assurance processes. The Board could not find adequate application of
a process, database, or metric analysis tool that took an integrated, systemic view of the entire
Space Shuttle system.

Detail Causes 4. Lack of integrated management

across program elements

Ability to Operate in Both a Centralized and Decentralized Manner - The ability to operate in a centralized manner
when appropriate, and to operate in a decentralized manner when appropriate, is the hallmark of a high-reliability
organization. On the operational side, the Space Shuttle Program has a highly centralized structure. Launch
commit criteria and flight rules govern every imaginable contingency. The Mission Control Center and the Mission
Management Team have very capable decentralized processes to solve problems that are not covered by such
rules. The process is so highly regarded that it is considered one of the best problem-solving organizations of its
type.17 In these situations, mature processes anchor rules, procedures, and routines to make the Shuttle
Programs matrixed workforce seamless, at least on the surface.
Nevertheless, it is evident that the position one occupies in this structure makes a difference. When supporting
organizations try to push back against centralized Program direction like the Debris Assessment Team did
during STS-107 independent analysis generated by a decentralized decision-making process can be stifled. The
Debris Assessment Team, working in an essentially decentralized format, was well-led and had the right expertise
to work the problem, but their charter was fuzzy, and the team had little direct connection to the Mission
Management Team. This lack of connection to the Mission Management Team and the Mission Evaluation Room
is the single most compelling reason why communications were so poor during the debris assessment. In this
case, the Shuttle Program was unable to simultaneously manage both the centralized and decentralized systems.
The Space Shuttle Systems Integration Office handles all Shuttle systems except the Orbiter. Therefore, it is not a
true integration office.
When the Integration Office convenes the Integration Control Board, the Orbiter Office usually does not send a
representative, and its staff makes verbal inputs only when requested.
System safety engineering and management is separated from mainstream engineering, is not vigorous enough to
have an impact on system design, and is hidden in the other safety disciplines at NASA Headquarters.
There are conflicting roles, responsibilities, and guidance in the Space Shuttle safety programs. The Safety &
Mission Assurance Pre-Launch Assessment Review process is not recognized by the Space Shuttle Program as a
requirement that must be followed (NSTS 22778). Failure to consistently apply the Pre-Launch Assessment
Review as a requirements document creates confusion about roles and responsibilities in the NASA safety
organization.
Risk information and data from hazard analyses are not communicated effectively to the risk assessment and
mission assurance processes. The Board could not find adequate application of a process, database, or metric
analysis tool that took an integrated, systemic view of the entire Space Shuttle system.
When the Integration Office convenes the Integration Control Board, the Orbiter Office usually does not send a
representative, and its staff makes verbal inputs only when requested.

Detail Causes: 5. Evolution of an informal chain of

command and decision-making processes that
operated outside the organizations rules

There are conflicting roles, responsibilities, and guidance in the Space Shuttle safety
programs. The Safety & Mission Assurance Pre-Launch Assessment Review process
is not recognized by the Space Shuttle Program as a requirement that must be
followed (NSTS 22778). Failure to consistently apply the Pre-Launch Assessment
Review as a requirements document creates confusion about roles and
responsibilities in the NASA safety organization.
The failure to convey the urgency of engineering concerns was caused, at least in
part, by organizational structure and spheres of authority. The Langley e-mails were
circulated among co-workers at Johnson who explored the possible effects of the
foam strike and its consequences for landing. Yet, like Debris Assessment Team CoChair Rodney Rocha, they kept their concerns within local channels and did not
forward them to the Mission Management Team. They were separated from the
decision-making process by distance and rank.
Similarly, Mission Management Team participants felt pressured to remain quiet
unless discussion turned to their particular area of technological or system expertise,
and, even then, to be brief. The initial damage assessment briefing prepared for the
Mission Evaluation Room was cut down considerably in order to make it fit the
schedule. Even so, it took 40 minutes. It was cut down further to a three-minute
discussion topic at the Mission Management Team. Tapes of STS-107 Mission
Management Team sessions reveal a noticeable rush by the meetings leader to the
preconceived bottom line that there was no safety-of-flight issue. Program
managers created huge barriers against dissenting opinions by stating preconceived
conclusions based on subjective knowledge and experience, rather than on solid
data. Managers demonstrated little concern for mission safety.

Team # ____ Student Name_________________________________

Columbia Accident

1. Lack of Commitment to a Safety Culture

Organizational problem/
Detrimental Practice

Who
was
involved?

Impact on
accident?

Your ideas for

Recommended
solutions

Team# ____ Student Name_____________________________________________

Columbia Accident
2. Reliance on past success as a substitute for sound engineering practices
Organizational problem/
Detrimental Practice

Who
was
involved?

Impact on
accident?

Your ideas for

Recommended
solutions

Team# __

Student Name________________________________________________

Columbia Accident

3. Lack of clear communication

Organizational problem/
Detrimental Practice

Who
was
involved?

Impact on
accident?

Your ideas for

Recommended
solutions

Team# ____

Student Name____________________________________________

Columbia Accident

4. Lack of integrated management across program elements

Organizational problem/
Detrimental Practice

Who was
involvinvolved?

Impact on
accident?

Your ideas for

Recommended
solutions

Team # ____

Columbia Accident Student Name_______________

5. Evolution of an informal chain of command and decision-

making processes that operated outside the organizations rules

Organizational problem/
Detrimental Practice

Who was
involved?

Impact on
accident?

Your ideas for

Recommended
solutions

Your Team Project

Program Plan for the Life Cycle
4 or more on each team will be assigned
Choose a team (1) Program Manager, (2)
a Chief Engineer, a (3) Lead Business
Ops person, and a (4) Lead Systems
Engineer
Choose an Aerospace Program that is
Your ARO 491,2,3 Senior Design Project

Project Plan General Outline

1.
2.
3.
4.
5.
6.
7.
8.
9.

Needs, Goals, Objectives

Requirements
Task Statements, SOW
Work Breakdown Structure
Technical approach
Schedule
Org chart/staffing/task resp matrix
Budget & Earned Value Mgmt
Risk Analysis

Resp.
Prog Mgr
LSE
Bus Ops
Chf Eng
Chf Eng
Bus Ops
Prog Mgr
Bus Ops
LSE

Deputy
Bus Ops
Chf Eng
Pgm Mgr
LSE
LSE
Prog Mgr
Bus Ops
LSE
Chf Eng

ARO 420 Class Project

Team # _____ Team Name______________________

Title of Project __________________________________________________
Type of System or Process ________________________________________
RFP source and title:
_______________________________________________________
______________________________________________________________
Team members: _________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Team Leader #1 _____________________________________________
Deputy Leader ________________________________________________
General Description of this project
____________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________

End session # 2

Back-up

Activity: What are the Key Problems that Program

Management Must Overcome?
Activity: Table Discussion & Report on Flip Chart

Potential Answers:
1. Schedule slippage
2. Cost over runs
3. Technical Performance deficiency
4. Poor definition or late requirements
5. Poor planning
6. High risk technologies needed
7. Inadequate technical skills available to the program
8. Lack of team work
9. Poor communications and coordination
10. Insufficient monitoring of progress and cost status
11. Inadequate corporate support
12. Adversarial customer

What are some ways the program management

can overcome Key Problems?
Activity: Choose two of the problems and propose a solution
Table Discussion & Report on Flip Chart

Problem
1.
Schedule slippage
2.
Cost over runs
3.
Technical Performance
deficiency
4.
Poor definition or late
requirements
5.
Poor planning
6.
High risk technologies needed
7.
Inadequate technical skills
available
8.
Lack of team work
9.
Poor communications and
coordination
10. Insufficient monitoring of
progress and cost status
11. Inadequate corporate support
12. Adversarial customer

Solution
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

What are some ways the program management

can overcome Key Challenges?
Problem
1.
Schedule slippage
2.
Cost over runs
3.
Technical Performance
deficiency
4.
Poor definition or late
requirements
5.
Poor planning
6.
High risk technologies needed
7.
Inadequate technical skills
available
8.
Lack of team work
9.
Poor communications and
coordination
10.
Insufficient monitoring of
progress and cost status
11.
Inadequate corporate support
12.
Adversarial customer

4.

Ways for PM to overcome problems1

5.
7.
8.
9.
1,2,3
,10

, and formal Earned Value Management

11.
12. Make your customer an integral part of your team decisions, seriously
consider to his suggestions, communicate on a weekly basis!
1

Eisner, Howard, Project and Systems Engineering Management