Jump to content






A Challenge to Contracting

Posted by Vern Edwards, 11 January 2009 · 590 views

Bob posted a report on the homepage last week: The Challenge of Contracting for Large Complex Projects: A Case Study of the Coast Guard's Deepwater Program. It says that when the government hires a contractor to develop a system that is comprised of independent systems that must work together, the job is so complex and entails so much uncertainty and risk that the government cannot contract the way it does to buy simple things. It then says that before the government can fashion a suitable approach it must (1) have enough competent people, (2) understand the risks involved, and (3) learn about the special problems associated with the development of systems of systems.

In order to understand what the authors wanted to say, but didn't say especially well, we must understand systems of systems and the challenges that they pose to engineers and contracting officers.

Systems of Systems

Here is the definition of system in the Glossary of Defense Acquisition Acronyms and Terms, 12th ed. (Defense Acquisition University Press, 2005), p. B-159:
System 1. The organization of hardware, software, material, facilities, personnel, data, and services needed to perform a designated function with specified results, such as the gathering of specified data, its processing, and delivery to users. 2. A combination of two or more interrelated pieces of equipment (or sets) arranged in a functional package to perform an operational function or to satisfy a requirement.
Now here is the definition of system of systems, p. B-161:
System of Systems (SoS) A set or arrangement of interdependent systems that are related or connected to provide a given capability. The loss of any part of the system will significantly degrade the performance or capabilities of the whole.
An aircraft carrier is a system. A carrier strike group is a system of systems. Go here for a description of a carrier strike group:


The Engineering Challenge

The components of a system of systems are themselves independent systems, each of which could work alone. In order to work together they must be functionally and physically integrated. Development takes place in an environment of changing political, social, and economic conditions, and sometimes rapidly evolving technology. Thus the development of a system of systems is awash in uncertainty and risk.

The engineering challenge was described in "System of Systems Engineering," by Keating, et al., Engineering Management Journal (Sept. 2003):
There seems to be little argument concerning present shortcomings in our abilities to deal with difficulties generated by increasingly complex and interrelated systems of systems. Beer's (1979) observation about complex systems still holds ‐ we are dealing with a jigsaw puzzle that is about five miles across and we are standing on the ground trying to see how to fit it together. Since Beer's observation unprecedented explosive growth has taken place in technology, artifacts produced by technology, and information access has risen exponentially. However, we seem no more able to address Beer's puzzle than when he identified it over 20 years ago. In fact, it appears that we now have a problem centered on integrating multiple five-mile diameter jigsaw puzzles that change as we try to fit the pieces together?

Traditional systems engineering approaches successfully addressed narrowly defined and well‐bounded problems. In fact, Schon (1986) suggests that engineering disciplines have been directed at clearly defined problems, relatively clear goals, and can be attacked from an established body of proven theory and knowledge. These conditions are no longer the rule, but the exception in rapidly evolving system of systems problem contexts. Increasing information intensity, contextual richness, and problem complexity all contribute to the need for evolving systems engineering to address emergent complex systems problems. The finite phases of traditional systems engineering blur with the demands of engineering a system of systems?

In traditional systems engineering, establishing goals (objectives) for the system have been assumed to be: (1) capable of definition, (2) fixed, and (3) unitary [single, explicit, agreed upon]. In effect, once explicit goals for the system were defined, they were fixed. Subsequent analysis could move forward, always having a fixed reference point in the system goals. While this might have been plausible in past systems engineering, it is no longer a given reality. On the contrary, SoSE [system of system engineering] environments are most likely characterized by ill‐defined and potentially tacit divergent goals (pluralistic) that are value laden, shifting, and incapable of being made entirely explicit. For example, two major contractors may be working on a joint standard, each with a set of tacit objectives having nothing to do with defined system performance goals, but more with desires of profitability and power. SoSE environments and approaches must be designed to consider and account for pluralistic dynamic system goals.
You can search for the complete article at:

The Contracting Challenge

The contracting challenge comes when the government hires a contractor to develop a system of systems, as it did for the Army's Future Combat System and the Coast Guard's Deepwater program. Such programs are ill-served by today's contracting rules, procedures, and culture, which are founded upon the expectation of more or less fully specified requirements and competitions based on proposed performance outcomes and price. That approach doesn't work well when the government wants to hire a contractor to determine the requirements and then design and produce the solution.

Contractors that are hired to develop systems of systems are called lead system integrators.
The Congressional Research Service has defined lead systems integrator as follows:
[A] contractor, or team of contractors, hired by the federal government to execute a large, complex, defense-related acquisition program, particularly a so-called system-of-systems (SOS) acquisition program.
Due to its experience with the Future Combat System and Deepwater, Congress now looks upon such contractors with suspicion. See the Congressional Research Service's August 20, 2008 report RS22631, Defense Acquisition: Use of Lead System Integrators (LSIs) ? Background, Oversight Issues, and Options for Congress. Find it at:


The relationship between the government and a lead systems integrator does not conform to the expectations of our FAR-based culture. The old-time, command-style ("the Contractor shall"), hold-their-feet-to-the fire approach doesn't work well when the contractor was hired to build the fire.

Contracting professionals write contracts so that programs can use taxpayer money, and in order to specify results and distribute risk. They are enablers. But when developing a system of systems it is impossible to fully specify all output at the time of contract award, and risks cannot be fully defined. So contracts are incomplete, with some things left to be stipulated in the future. Ironically, the contract must be incomplete so that the parties can be free to adapt as the program goes forward. The existing machinery for changing contracts is clunky and slow. If the contract isn't incomplete it will not enable the parties, it will hinder them, trip them up, and slow them down.

In order not to hinder the execution of large, complex programs, the contracting community must leave Planet FAR and develop policies, procedures, and contractual instruments that are suited to challenges of developing systems of systems. First, they must develop ways to select contractors without proposed prices or estimated costs for specified quality and delivery. (How do you conduct a quality/price competition for such work? The technical proposal is science fiction, the management proposal is an MBA candidate's fantasy, and the most you can do with price is to hold an hourly rate contest.) Second, they must write contracts that establish goals and relational protocols instead of results. Third, they must figure out how to fairly compensate contractors in the face of evolving needs, high levels of uncertainty, and ill-defined and ever-shifting risk. And fourth, they must rethink their ideas about quality assurance and the duties and authority of contracting officers' technical representatives.

Finally, contracting professionals must figure out how to evaluate and work effectively with the new breed of metacontractors⎯giant, complex entities that are themselves comprised of complex entities. An example is Deepwater's Integrated Coast Guard Systems, which is comprised of Northrop Grumman and Lockheed Martin⎯two titans, each with its own history, culture, skills, and objectives. We call them "teams," and they sometimes are. But sometimes they're just unhappy and unsuccessful partners in a marriage of convenience. We must figure out how to choose them competitively, how to establish an effective relationship with the chosen one, and how to keep the relationship on track.

Contracting pros have a lot of interesting and important problems to solve in order to be useful to their clients: the agency heads and the managers of our largest, most complex, and most important programs. More such programs are coming, and the need for better contracting support is critical. The contracting community must think things through and then persuade Congress to let them use better-adapted ways of doing business. Solving those kinds of problems will lead to better program execution, and to professional recognition, prestige, and advancement. Most importantly, it will contribute to our national security, success, and well-being.

You don't have to wait for authorization to get started. Observe. Read. Think. Discuss. Write. For a start, take a look at the article that Ralph Nash and I wrote for the Defense Acquisition Review Journal (Sept. 2007), "A Proposal for A New Approach to Performance Based Services Acquisition." Find it here:
Defense Acquisition Review Journal.




Nice entry, Vern. You focused (righfully) on the impact of complex projects on contract/acquisition management. I have been dealing with the impact on program management. It's apparent that the shortcomings you noted with respect to "contracting pros" are just as applicable -- if not more so -- to DOD's program managers.

A recent book, Reinventing Project Management (Aaron Shenhar, Harvard Business School Press, 2007) discusses how the approach to managing a project needs to adapt to the attributes of the project. (This is similar to your point that that approach to contracting needs to adapt to the attributes of what is being acquired.) Shenhar suggests that four project attributes will drive the project management approach: (1) novelty (how new the product is to the market, customers and potential users; (2) technological uncertainty or maturity; (3) complexity of the project (what is being managed, which is measured via a spectrum ranging from a single component to an "array" or system of systems; and (4) pace (urgency/criticality of meeting schedule goals. Shenhar expressly rejects the "triple constraint" of cost/schedule/performance because (among other things) those are outcomes not a management approach.

I highly recommend Shenhar's book, which might be used as a foundation for addressing shortfalls in contract management as well.
  • Report

Recent Comments

Tags

    October 2014

    S M T W T F S
       1234
    567891011
    12131415161718
    192021222324 25
    262728293031 

    0 user(s) viewing

    0 members, 0 guests, 0 anonymous users

    0 user(s) viewing

    0 members, 0 guests, 0 anonymous users