Systems Engineering and Acquisition: Itís time for a new way
Mr. Norman is the Director of Complex Systems Engineering in the Center for Command and Control. He is part of a small group responsible for cross-corporate systems engineering at enterprise scales.
Mr. Norman’s interests include the science of complex adaptive systems, emergent behavior – including technologies and techniques to understand and manage such characteristics. He is actively engaged in research and scholarship in
this area, particularly in applying complexity theory to the general area of Systems Engineering. He is published in this area, and is a speaker in demand at many conferences on this topic.
He is the MITRE connection to the New England Complex Systems Institute (www.necsi.org) and to the Sloan School of Management at MIT. He is adjunct faculty at both UCSD and Johns Hopkins in Systems Engineering.
Additionally, he is interested in the business of technology where he has both started businesses and has mentored business and technology students who have gone on to start high-tech businesses. He and a team of his won the Business Idea Competition at Cornell in 2002 which resulted in venture funding of the team. That same year another team he mentored garnered a quarter-finalist position in the MIT “50K” business competition.
Mr. Norman has held a series of positions focused on the engineering of very large systems. Prior to his current position, he was the Section Leader for Command and Control / Battle Management (C2/BM) in the Air Force Center. In this role he exerted direct influence across all AF BM/C2 programs. Before being a Section Leader, Mr. Norman was Chief Engineer for Theater Battle Management Core Systems (TBMCS), and for Air and Space Operations Center – Weapon System (AOC). TBMCS was the key system used in Operation Iraqi Freedom to plan and manage the air war. In this position, he redefined and launched TBMCS on a new vector: architecturally, technically, organizationally, and philosophically. TBMCS became the first major program to embrace “netcentricity;” and delivered netcentric capabilities into the field prior to Operation Iraqi Freedom. It is now viewed as a template for transforming to Service-Oriented Architectures.
Mr. Norman has an MS in Computer Science from the Air Force Institute of Technology (AFIT) with specialties in Computational Theory and Artificial Intelligence. He also completed all but dissertation for the Ph.D. in Neurobiology from SUNY@ Stony Brook.
Mr. Norman has a diverse set of non-work interests which include flying (he is a certified flight instructor and an advanced ground instructor), diving, sailing, and enjoys playing jazz and blues as a bassist.
Systems Engineering, as currently practiced, is a disciplined transformation of requirements into delivered capabilities. Sounds correct, doesn’t it? Who could argue? Well… while it worked at one time, and still works at a certain size and scale, it doesn’t work for much of what’s being procured today. Why not? What might we do differently?
Systems Engineering is predicated on four assumptions. That for every system:
1. There are a set of requirements for building it;
2. That the requirements remain stable over time and over organizations;
3. That we can “know” these requirements; and,
4. That the process steps which gather and transforms requirements into “systems” is a lossless, clean one.
The Acquisition System, writ large, makes its own assumptions:
1. That Systems Engineering, constrained to requirements and technological lanes, is sufficient to define and build valued systems;
2. That one can scope and price anything to be built a priori, and,
3. That “operational value” is equivalent to “meeting the requirements.”
These two sets of assumptions collaborate in an undesired result: failed systems acquisitions. Yet they persist. One would hope that change could start with a change of mindset and perspective of those engaged in the current activities.
Examining the assumptions, and testing them against our experience, shows that the assumptions are flawed. Yet the marriage continues almost unabated. A recent bill introduced by senators Levin and McCain, (s 454 Weapon Systems Acquisition Reform Act of 2009), attempts to take on this continuing problem, yet one can question whether it’s likely to have any success at all as it is aimed at more careful oversight and better requirements. It doesn’t seem to touch the “system.”
What might we do differently? Many of us are taking a new approach to this area. We’re adapting “complexity” as a framework which fits the actual behavior we’ve seen and aligns with our experiences. We’ll discuss “complexity” and how it offers a different model and framework for augmenting our current Systems Engineering and Acquisition systems. We’ll discuss how such a framework for approaching Systems Engineering feeds well into complementary acquisition approaches.