Table of Contents
- The Development of Partnering
- Partnering in the Construction Industry
- The Army Corp of Engineers Endorse Partnering
- How Partnering Is Possible in Todays Government Environment
- Conflict and How to Deal with It
- Partnering on Your Program
- Appendix A: Recommended Contract Clauses (Section H)
- Appendix B: "Is It Working?" Questionnaire
Partnering is primarily a relationship in which program stakeholders work, cooperate, and perform in good faith as a unified team. Partnering is similar to picking teams for a tug of war at the company picnic. Each team is together for the duration of the competition and the "partners" know that they must work together to succeed. If the partners do not pull in the same direction, hold on to the rope, and dig-in with their feet, the team will not finish successfully.
In the acquisition of government systems, the program is the rope that unites the program partners. Accordingly, the partners are required to put aside individual interests and work together, communicate their expectations, agree on common goals and methods of performance, and identify and resolve problems early, before losing the opportunity for success.
The Army defines partnering as: "A project-specific interorganizational dispute-avoidance process." It is "project specific" because the Competition In Contracting Act (CICA) does not permit long term government commitments to individual companies that exceed the duration of the competitively awarded contract. It is "inter-organizational" because it joins a number of different organizations into a single project team. "Dispute avoidance" refers to the way partnering works to eliminate the root causes of conflict. It is a "process" because philosophy is not enough. By developing a specific process, participants have guidance tools rather than just good intentions.
The Army limits the partnership to the acquisition agency and the contractor in the period after contract award. We have the opportunity to extend the concept to include the using and the acquisition agencies before award, and adding the contractor to the team after contract is awarded.
This document outlines the development of partnering, describes its benefits, and offers some suggestions for use on MITRE programs. In addition to references cited in the text, the bibliography lists sources of information related to partnering.
A brief history of how partnering came about in our environment starts with the construction industry, which has used partnering for a number of years.
In 1994, the Construction Industry Dispute Avoidance and Resolution Task Force (DART) surveyed 8,000 attorneys, design professionals, and contractors. The design professionals viewed project partnering "as a superior method" for achieving desired results, and the contractors were "extremely favorable toward the prospects of project partnering and tended to view it as a highly effective vehicle for achieving a host of goals on construction projects." More than 70 percent of all three groups predicted future increases in the use of partnering. The design professionals and attorneys indicated that favorable experiences with partnering outnumbered unfavorable experiences by five to one.
Recognizing the success in the construction industry, the Army Corps of Engineers experimented with the concept. Their success has prompted them to adopt a policy of developing, promoting, and practicing partnering on all construction contracts and to expand the concept to other relationships. The Corps defines the concept this way:
Partnering is the creation of an owner-contractor relationship that promotes achievement of mutually beneficial goals. It involves an agreement in principle to share the risks involved in completing a project, and to establish and promote a nurturing partnership environment. Partnering is not a contractual agreement, however, nor does it create any legally enforceable rights or duties. Rather, partnering seeks to create a new cooperative attitude in completing government contracts. To create this attitude, each party must seek to understand the goals, objectives, and the needs of the other -- their "Win" situation -- and seek ways that these objectives can overlap.
Delivery of an operationally useful system on time or early, and on or under budget, is a win situation for the user, the acquisition agency, and the contractor. Program success is a powerful incentive for all the partners and eliminates the disincentives associated with failure to achieve technical, cost, or schedule goals.
The Office of Federal Procurement Policy recognized the success that the Army Corps of Engineers and several other federal agencies have achieved in construction projects and has recommended (as a "Best Practice") the implementation of partnering principles in the automated data processing/information resources management areas.
The direction from the Secretary of Defense in DoD 5000.2-R to implement Integrated Product and Process Development (IPPD) and Integrated Process Teams (IPTs) encouraged and enabled partnering throughout the Department of Defense (DoD). The Air Force Electronic Systems Center supports the concept and has already demonstrated successful partnering efforts that involve the user, the acquisition organization, and the contractor.The Evolution of IPTs
IPPD is the latest phase of the Total Quality Management (TQM) initiative adopted by the American automotive and consumer electronics industries in the early 1980s. The adoption of TQM philosophy was in response to the market share lost to the Japanese manufacturers who had implemented TQM in their manufacturing processes. One of the key TQM areas was the Design For Manufacturability (DFM) early in the conceptual stage of product development. This permitted a faster concept to market cycle than the serial design and manufacturing engineering processes used in American industry. In the mid 1980s, American industry supplemented the early TQM initiatives with Concurrent Engineering (CE) and IPTs. These two additions permitted the involvement of manufacturing, support, marketing, and other "illilties" early in the design process. The implementation of IPTs moved the focus away from the functional departments and toward the product being developed. It introduced teamwork as part of a major system development process.Department of Defense Enables Partnering
In the new version of DoD 5000.2-R, the Secretary of Defense directs "that the department perform as many acquisition functions as possible, including oversight and review, using IPTs." The regulation also endorses the use of "government-industry partnerships" as a best practice, but points out that the participation of prospective contractors before award be in accordance with procurement integrity rules and requires legal review. DoD Directive 5000.1 states that "Program IPTs focus on program execution, and may include representatives from both government, and after contract award, industry."Air Force Material Commands Electronic Systems Center Recognizes a Need for Partnering
In their draft reengineering team report, the Electronic Systems Center (ESC) recommended the formation of "strategic partnerships" early in the program. The following summarizes their recommendation:
"A successful program is dependent on establishing strategic partnerships early. Working with both the user and industry early can lead to a program where everyone understands what is wanted and there are few surprises. An atmosphere of disciplined trust, where everyone understands each other's role and respects it, is fundamental to reducing the risks of other (more radical) tenets of acquisition reform.
The optimum process would start with a dialog between the user and the acquisition agency like:1) Let's work together to understand your requirements.
2) Let's get industry involved up front to perform tradeoffs and contribute to our risk assessments.
3) Let's agree up front what we will do for you.
4) Let's form a strategic partnership for the duration of the effort among the user, ESC, and industry."
The ESC strategic partnerships fall into two categories: 1) those involving users and potential contractors participating in Cooperative Research and Development Agreements (CRDAs) and 2) those involving the user and the selected contractor for any given program.
The partnerships involving potential contractors are best illustrated with the Command and Control Unified Battlespace Environment (CUBE) efforts that provide an interoperability showcase for participating CRDA contractors to demonstrate their products to users. Since the Competition In Contracting Act precludes limiting the competition for any particular contract to the participating CRDA contractors, ESC uses Requests for Information, Presolicitation Conferences, the Hanscom Electronic Request for Proposal Bulletin Board (HERBB), and draft Requests for Proposals (RFPs) to provide all potential contractors (including the participating CRDA contractors) with the opportunity to better understand user requirements and to provide inputs to government requirements tradeoffs and risk assessments while the RFP is being developed.
The second category of strategic partnerships involves the relationship between the ESC program office and the user (as well as other government stakeholders) in defining the requirements and the source selection factors for the acquisition in question. Although contractor inputs during RFP development are solicited and frequently accepted when they benefit the government (and don't give any one contractor a competitive advantage), the decisions regarding the requirements and source selection factors are a government responsibility. As the RFP evolves, the government requirements and source selection factor decisions are provided to all potential contractors on HERBB. The contractors deciding to bid submit proposals on their respective approaches and the source selection results in the award of one or more contracts. Once the contract is awarded, the selected contractor(s) can be included in the government stakeholder partnership for the duration of the program. The following discussion is limited to this second category of partnership--the program IPT.Benefits of Partnering
Without some change in our actions, we may think "IPT", but act the same old way and get the same old results. The recommended partnering process lets us change our actions and reap the benefits. Some examples follow:
- Reduced litigation. The Army Corps of Engineers has used partnering
on large and small contracts for over six years. To date, all reports indicate
that not a single dispute has gone to litigation on a partnered project. This
is in stark contrast to the number of disputes received on non-partnered
contracts of similar size and complexity.
- Successful, profitable contracts. Experience within the construction
industry has shown that partnering has resulted in completion on schedule, cost
overrun reduction by two thirds, reduction in paperwork by 66 percent,
increased value engineering, no lost time injuries, and other mutually
beneficial performance when compared to the average contract. The Kansas City
District of the Army Corps of Engineers found that, on average, a partnered
contract reduced cost growth by 2.65 percent, reduced modifications by 29
percent, and virtually eliminated time overruns (averaging 26 percent). Another district, the Portland District Army
Corps of Engineers, discovered a two thirds reduction in paperwork.
- Improved morale. Evaluations conducted under previous Army partnering
contracts has shown a distinct improvement in the morale of the people working
on the contract. When people can work in a conflict-free environment, they can
concentrate on the job rather than on potential claims, and the morale and
effectiveness of the whole "team" is improved.
- International success. USSOCOM has been given acquisition authority by
Congress that is equal to the services. Thus, for USSOCOM managed programs, the
user and the acquisition agency are part of the same command. On the
Directional Infrared Countermeasures (DIRCM) program, USSOCOM implemented IPTs
that involved all the stakeholders (including the United Kingdom Ministry of
Defence, the contractors, and external organizations) for the program. They
have been happy with the implementation of the concept and claim success with
Partnerships and IPTs are formed to facilitate concurrent problem solving. Both concepts involve the interaction of disparate groups to solve complex problems. If all parties in an acquisition were of like mind, then there would be no need for either IPTs nor partnerships. However, this is not the case. Many of the "stakeholders" in the acquisition of a major system come from different cultures and have different value systems and vocabularies. For example, the stakeholders may include the following groups:
- Mililtary personnel
- Civil service personnel
- Government program office core personnel
- Government acquisition matrix support personnel
- Funded Research and Development Center (FFRDC) core and specialty personnel
- Technical, Engineering, and Management Services (TEMS) contractor personnel
- Government logistics support personnel
- Government personnel from interfacing programs
- Government personnel from independent test and evaluation organizations
- Government personnel from security or other accrediting organizations
- Using command operations personnel
- Using command support personnel
- Prime contractor personnel
- Subcontractor personnel
- Commercial Off-The-Shelf (COTS) suppliers
- Associate contractor personnel from interfacing programs
Conflict is a disagreement between two or more parties. The issues in conflict are typically either substantive (such as allocation of resources, policies, procedures, requirements) or over emotional (such as values, culture, management style, personal preferences, distrust). Frequently, conflicts involve both types of issues. Conflict can range in intensity from a minor irritant to a major problem that threatens the success of the entire program.
Research indicates that a typical manager spends 20 percent of his or her time resolving conflicts and disagreements. The DoD 5000.2-R direction to implement the use of IPTs changes the role of the typical manager. The empowerment of IPT members and IPT leaders delegates some of the program management authority and increases the number of individuals required to deal with conflicts and disagreements. With the increased use of IPTs, there are numerous opportunities for conflict. Although the senior representatives of the participating organizations may be equipped to deal with conflict, many of the individuals on the IPTs have not had either training or experience in conflict management.
The Defense Systems Management College (DSMC) Program Manager's handbook points out that conflict has been traditionally viewed as a negative factor, and if it is present, organizational management has failed. The handbook also points out a new perspective:
- "The contemporary view of conflict is that it is not inherently good or bad,
but is neutral. According to this philosophy, conflict is a process in which
incompatible goals, interpretations, or emotions of individuals or groups lead
to opposition. Conflict can be beneficial and productive, contributing to
effective problems-solving and serving as a change agent for the parties
Here are some constructive ways of dealing with conflict and some recommendations for successfully implementing program IPTs on major programs.
The DSMC Program Manager's handbook indicates a number of sources of conflict within a Program Management Office (PMO) and discusses the role of the program manager (PM) in dealing with this conflict. The PM continues to have a major role in dealing with conflict within the PMO. However, we will also examine those sources of conflict in a broader context that considers the entire program and the participation of the user, the contractors, and other external organizations in program IPTs. Sources of conflict include:
- Ambiguous Roles. IPT members' clear understanding of their roles and
responsibilities can minimize conflict. IPT members are expected to represent
their functional specialties, understand how their specialty needs to be
tailored for the product being developed by the IPT, promote the success of the
IPT product, and promote the success of the overall program. Each team member
needs to have a clear understanding of the responsibilities and authorities
given to them by their sponsoring organizations. They must also have a clear
understanding of the goals of the IPT and how they are expected to contribute
to the achievement of these goals. Each IPT and its members must be aware of
its responsibilities associated with requirements, priorities, costs,
resources, and timing. A well developed Integrated Master Plan (IMP) will spell
out the roles of the contractor(s), but the PM and functional organization
supervisors are responsible for identifying the roles and constraints on the
- Inconsistent Goals. The opportunities for inconsistent goals with the
number of organizations involved abound. The user is preparing for war. The
acquisition agency is developing products. The functional organizations
supporting the program office are concerned about their respective "illities."
The FFRDC is concerned about system engineering and interoperability. The
logisticians are concerned about sustainability. The contractors are concerned
about profit and reputation. The test organization is concerned about
operational suitability. The security organizations are concerned about
protecting their sources. It is important that the IPT members develop mutual
goals for the success of their IPT. However, the IPTs also need "overarching"
goals that lead to the success of the program and are not suboptimized at the
IPT level. A well developed Statement of Objectives (SOO) with clearly stated
program and contract objectives is a good start in developing the required set
of overarching goals.
- Communication Barriers. Research indicates that communication barriers
exist and create misunderstanding in most organizations. This is compounded by
the functional and acquisition vocabularies in the program office, the
operational vocabulary of the user, the logistics community vocabulary, the
security community vocabulary, and the contractor vocabulary. On joint service
or multinational programs, the communication barriers are even more
significant. In addition to the differences in vocabularies, cultural and value
system differences need to be considered. Only patience and the ability of IPT
members to listen and understand the positions of the other IPT members and
then to explain their position in the context of the IPT product development
process will contribute to overcoming these barriers.
- Delegation of and Limits to Authority. Empowerment of the IPT members
by their respective organizations is key to the success of an IPT. IPT members
without the authority to speak for their sponsoring organization impede the
development process. There are some legal limits to empowerment in dealing with
government contractors, and government personnel must be careful to avoid
"constructive changes" to the contract. Likewise, an IPT cannot change cost,
schedule, or requirements thresholds contained in the Acquisition Program
Baseline (APB) for the program. Thus, the delegation of legitimate authority to
IPT members and stating the limits of their authority are essential to the
success of an IPT.
- Program Priorities and Schedule. IPT members may differ on the
sequence of important activities and tasks necessary to achieve successful
project completion. The IMP and the Integrated Master Schedule (IMS) developed
by the contractor in the proposal provide the initial roadmap for how the
contractor-run (the contractor has the responsibility to design, develop, and
deliver) IPTs will execute the program.
These documents indicate the sequence and timing of the tasks necessary for
each of the IPTs to complete their portion of the program. Following contract
award, the government and the user should become members of the contractor's
IPTs and, if necessary, together with the contractor, modify the IMP and IMS to
reflect a joint strategy for program execution. The agreement on the IMP and
the IMS by the IPT and adherence to the agreed upon IMP and IMS are essential
to the success of the program. The IMP and IMS should be treated as "living
documents" and changed by the IPT, if necessary, to reflect changes in risk,
priorities, funding, requirements, schedule, etc.
- Resource Allocations. No program has unlimited resources (funds,
manpower, facilities, etc.) with which to accomplish all activities,
requirements, or tasks that seem worthwhile. The implementation of the Cost As
an Independent Variable (CAIV) concept, directed by DoD 5000.2-R, makes it
necessary to prioritize requirements to meet program cost objectives before the
RFP is released. If there is a fixed
budget and the cost of achieving the original set of requirements increases as
the program develops, the budget decreases, or the operational requirements
change, the agreements that have been reached on requirements priorities must
be renegotiated. Because of the strong possibility of changes in the
operational environment, cost growth, and funding cuts on government programs,
the user must be deeply involved in the requirement-cost tradeoffs, starting
with program definition and continuing through production.
- Lack of Information. The IPT members need to be kept informed. This
information has several dimensions. Changes in program or subsystem risk,
schedule, funding, priority, or requirements needs to be communicated as soon
as possible to the IPTs to permit them to alter their plans to meet revised
program plans. The IPT members need to be able to share information on the
product being developed to make informed decisions. The use of electronic data
on a server that is accessible to all IPT members is one technique for sharing
the required information. The IPT members also need to be kept updated on
changes in policy, procedures, or requirements by their sponsoring
organizations. And last, but far from least, the IPTs need to provide
information back to the program office and their sponsoring organizations on
decisions, activities, changes, problems, successes, etc., resulting from IPT
- Resistance to Change. Changes in the acquisition process, reductions in resources, and the implementation of IPTs are resulting in significant changes in the way in which systems are developed. Conflict results when people perceive threats to their authority and tradition. The government and contractor program managers and the senior user representative must be conscious of the impact of program changes on their personnel. These individuals need to "sell" changes to their personnel in terms of program objectives and constraints. The maintenance of top-level documents like the SOO and the IMP in response to program changes is a good follow-up step to selling the changes.
Conflicts between the user and the acquisition agency can be caused by incomplete understanding of the user's requirements, inability of the contractor to deliver the promised product due to cost growth (under-bidding the contract, unforeseen difficulties, etc.), changes in user demand for the product, user concerns about development process efficiency, and user disappointment in the evolving or final product. The disputes can lead to significant delays in the development of the product, "requirements adjustments," or the correction of defects. Once on contract, delays are expensive--the program office and contractor "marching armies" continue to use resources even when the useful labor effort is at a standstill. These disputes typically take place in a constrained funding environment (note the DoD 5000.2 direction for Cost As an Independent Variable). Serious early or mid-program disputes can lead to the cancellation of the program since the user is responsible for program advocacy and submitting funding requirements. Disputes late in the program often force the user to take an unacceptable system rather than wait for funding and development of another system.
Conflicts between the acquisition agency and the contractor can be caused by requirements interpretation, lack of cost-realism during the bidding process, delays in completion of intermediate milestones, funding fluctuations, overestimated software productivity, and changes in user requirements. Like the user-acquisition agency disputes, these disputes can stop the progress but not the costs on the program. Unlike the user-acquisition agency disputes, these disputes can and have been referred to the courts.
Five basic conflict resolution strategies are identified by DSMC: avoiding, forcing, accommodating, compromising, and collaborating. Regardless of the source of the conflict, the "competing" or adversarial conflict resolution strategy typically employed when these conflicts occur, wastes significant manpower and dollar resources. In addition, it tends to cause resentment in the other party and a long-term deterioration of the business relationship among the parties.
The DSMC Program Manager's Notebook advises that the only strategy that optimizes the benefits to all of the parties involved is "collaborating."
- "Collaborating is jointly identifying change opportunities and seeking an
integrative solution -- the "win-win" approach. The conflict issue is
clarified, studied, and even redefined in an effort to give each party a goal
and solution that can be fully supported. Collaborating includes such
approaches as joint problem-solving, consensus-seeking, and establishing
superordinate goals (higher-level goals on which all can agree) in order to
achieve full cooperation. The major advantage of collaborating is that all
parties may be very satisfied with