1) Classical Systems Engineering and Program Management (CSEPM) aims to satisfy all system needs throughout development but in practice faces issues due to undefined requirements, inefficient subcontracting, and "sloppy" requirements. 2) A key flawed assumption of CSEPM is that all interfaces in complex systems can be defined, but this is unrealistic given human factors and unpredictability. Defining interfaces has led to problems with flowing down requirements and managing subcontractors. 3) The "Vee" model used in CSEPM proves unreliable for complex programs with thousands of requirements, as the critical assumption that all knowledge exists early on to define interfaces is often inaccurate.

1. CSEPM Final Essay
Professor Bohdan Oppenheim
SELP 630: Advanced Lean Management of
Engineering Programs
Damien Lewke
29 September 2015

2. Classical Systems Engineering and Program Management’s (CSEPM) purpose at its inception was a way
of systems thinking that satisfied “all needs during an entire system lifecycle” (Oppenheim 6). However
as a result of increasing bureaucracy and a lack of requirements definitions at the outset of a Program,
CSEPM’s true purpose has never been fully realized. As a result of an inherently flawed foundation,
undefinable interfaces, the inefficiencies of subcontracting, the CSEPM “Vee” and sloppy requirements
make efficiently managing and executing an advanced engineering program extremely difficult. As
discussed in lecture, CSEPM’s problems lie at the foundation of its execution. Specifically, CSEPM is
driven by an uncompromising need for unreliable systems and inefficient government acquisition
practices and incentives. This maligned foundation historically leads to high levels of program success,
such as the 80 successful space launches by the United States Air Force, but high costs and bureaucratic
delays continue to characterize these programs. Although attempts to reform these programs have
been made by reducing the number of requirements, systems engineering continues to bury itself in
increasing requirements. Although NASA’s Faster, Better Cheaper (FBC) programs sought to decrease
requirements and costs, 16 failures in the space of one decade answered the government’s questions
about fewer requirements. Instead of understanding that requirements were not fully understood at the
beginning of the effort, the government believed that a lack of oversight caused the additional mission
failures.
The Myth of Definable Interfaces has plagued CSEPM, particularly after the introduction of Model Based
Systems Engineering (MBSE). Although MBSE has been seen as an infallible way to conduct the systems
engineering, in fact the opposite is true. MBSE functions as a clerical tool rather than a requirement. It
provides no guarantee of the inclusion of all interfaces in a system design. Moreover, human wickedness
(unpredictability) dictates how MBSE is conducted. As the human wickedness impacts the system
design, the interfaces become inherently “wicked.” It is unrealistic that all interfaces in a complex
system can be identified; therefore, it is unrealistic to assume that all interfaces can be defined. This
critically flawed assumption has lent itself to the flow-down of System Requirements and
Subcontracting. A Classical Systems Engineer must insure that “the interfaces of each element of the
system or subsystem are controlled and know down to the developers.” With major programs’ multiple
tiers of subcontractors, specifying each interface (which we already know can be unpredictable) to each
subcontractor is nearly impossible. In addition, two major obstacles to efficiency lie in this assumption:
namely that the distribution of production to as many suppliers as possible and a company’s policy to
“stick to its core competencies and subcontract out the rest” is inherently inefficient. Often,
coordination between subcontractors and the prime contractor is slow, costs run high, and the
program’s finances take a severe downturn. For instance, in his paper earlier this year, Hatch-Smith
exposed the waste associated with the extreme degrees of subcontracting that Boeing employed with
the production of the Boeing 787. By subcontracting almost all of the effort’s design work, Boeing lost
money because subcontractors at each level demanded a profit on the work they performed. This
compounds per tier of subcontractors and, as discussed in class, major programs can have up to five
tiers of subcontractors.
In the face of a complex program with thousands of requirements like these, CSEPM’s cornerstone, the
“Vee,” proves almost completely unreliable. A fundamental example of the Vee’s inability to address
complex requirements is the Myth of the Single Cycle Vee. CSEPM’s methodology is based on the
“critical assumption that knowledge exists early in the program to anticipate all system interfaces.” In
order for the Single Cycle CSEPM to work, it must be performed perfectly the first time, because in a

3. single cycle, no one can go back in time. Given what we already know, interfaces will not be correctly
defined. In addition, when considering programs whose technology has begun to far outstrip their
management, defining all requirements at the outset of the program is impossible. This is especially true
in today’s defense industry, where CP contracts continue to pile requirements onto contractors and
subcontractors. An increase in requirements will trickle down to subcontractors, at which point
contracts will need to be renegotiated, a stipulation that these subcontractors will most likely not
comply with. As a result, even if the Program Manager addresses a potential change in requirements,
the subcontractors will operate independently. This stifles system optimization. One such example of
this, the Rocketdyne and Rockwell’s conflict in the design of the Space Shuttle Orbiter and Engine Filters,
illustrates this case. Rockwell’s orbiter required the proper flow rates and pressure, Rocketdyne refused
to test the engine with hazardously sized particles, and the companies failed to reach an agreement.
This resulted in the continued operation of the space shuttle throughout the rest of its career with these
significant hazards acknowledged but never addressed.
A counterargument in defense of CSEPM would be that MBSE could be utilized to correctly define
interfaces. However, this point was disproven above, as MBSE is a clerical tool rather than a
requirement. MBSE is just as unpredictable as those who designed and operate it, and therefore cannot
be used on its own to define a design’s requirements. In addition, the firms requesting many large
programs may not ever define the requirements. Oftentimes, junior personnel on a program are forced
to determine the requirements for an advanced system. Under pressure from the program, they will
literally “copy and paste” requirements from previous unrelated programs in order to meet the current
program’s deadlines. Sloppy requirements can lead to the example discussed previously, in which a
submarine’s specifications were used on the design of a satellite. This example clearly illustrates that the
employees attempting to determine requirements, in particular junior employees under pressure
regarding time, are not always equipped to do so.
Although CSEPM’s problems make the definition of requirements difficult and the execution of quality
products costly, several possible solutions to these problems exist. The first alternative is the counter to
the Faustian Bargain discussed in class. Pending a program’s submittal to a prime contractor, the prime
contractor can sign contracts with its subcontractors, thereby guaranteeing the subcontractors business
if the prime contractor receives the program. The prime contractor will define the requirements and the
subcontractor will be mandated to follow them. If the subcontractor refuses, the prime contractor will
simply find another willing subcontractor with which to do business. When addressing the issue of
sloppy and careless requirements, a few strategies can be adopted. Firstly, a third party may conduct a
highly rigorous and independent review before requirements are performed and released for the RFP or
contract. This reviewer should be able to catch all instances of unneeded and faulty requirements and
missing interfaces as well as dispute all “gold plated” requirements and demand that all deficiencies
identified be corrected before the program can proceed further. In this situation, all deficiencies are
identified before the RFP and contract’s execution, which eliminates costly requirement changing and
program rework. In addition, instating a responsible, accountable, and authoritative person to ensure
the development and delivery of all customer-level requirements could greatly improve inefficiencies
and poor requirements on a program.
Another far simpler way of eliminating poor program requirement definition is to almost do away with
them entirely. In the 1960s, the United States put men on the moon using four simple requirements: get
the men to the moon, get them back, do it safely, and do it before the end of the decade. These four

4. requirements began one of the most impressive achievements humankind has ever accomplished. In
nine years and with a flight system with less computing power than an iPhone, Neil Armstrong landed
on the moon on July 11, 1969. This paper argues that reducing requirements on a program ensures that
it is carried out more effectively and efficiently. Simply stating a vision and leaving program managers
and engineers who are passionate about what they are pursuing will produce a better product in a
shorter time, and at a far lesser cost than current advanced engineering programs. In lean, the respect
for people is core to the success of a program. By entrusting those who know and care about what they
are designing, true program success can be achieved.