Instructor's Note
This instructional case has been constructed using
a modular design, with the express purpose of supporting the pedagogy
of multiple courses, either as the basis of an in-class case discussion
or an outside reading on the subject. The kinds of courses for
which this case was designed include program management, contracting,
software, organizational behavior/change and others. Toward this
end, the case has been organized into seven sections. The five
sections in the middle (2-6) represent common, course-independent
material that comprise the fundamental case content that is applicable
to any of the courses listed above, whereas instructors are encouraged
to rewrite (or tailor) specific introductions and conclusions
(sections 1 and 7) for each alternative course. This approach
serves to support multiple courses by leveraging a single case
study research effort, and it reinforces the key idea that reuse
applies to more than just software code. As denoted by the title,
this particular case has been specifically tailored for use in
a software acquisition course. As such, the introduction begins
this case instance with a software-specific look at the JSOW program.
Copyright 1997 Mark E. Nissen
INTRODUCTION
Information technology (IT) is revolutionizing military affairs (Guenther 1996). IT comprises a "toolbox" of advanced capabilities that can be used for war fighting (Powell 1992). Incessant advances in the price/performance characteristics of IT support ever more-powerful software functionality in military weapon systems, communication systems, administration systems and a prolific mix of commercial and consumer technologies employed in the civilian sector. Looking at tactical military aircraft for example, the F-4 Phantom was practically devoid of software, whereas the F-22 currently in development is estimated to have eighty percent of its mission functionality supported by software (STSC 1996). Software has played a critical role even in the previous generation of fighters that the F-22 is designed to replace, as the F-16 Falcon, for example, employs software in its fly-by-wire flight control system to overcome the control problems inherent in its design with negative static stability; this (unstable) design is now common among tactical aircraft requiring high maneuverability, but without active control of flight surfaces (i.e., without software), "the F-16 is just a $15M lawn dart" (Ludwig 1992).
Additionally, missiles are now designed to navigate and fly autonomously, with software used to make in-flight decisions about course, angle of attack and targeting. Software supports the military infrastructure used for command, control, communications and intelligence (C3I), with examples like the Global Command and Control System (GCCS), Department of Defense (DoD) Common Operating Environment (COE) and other pervasive applications fundamentally enabled by software. In the Army Force XXI concept and the Army After Next, IT is planned to extend seamlessly from Corps-level command down through every layer to link individual tanks, aircraft, artillery and even soldiers in the field.
With this trend, the characteristics of acquisition management are changing dramatically; it is becoming the exception to manage a modern weapon system that lacks software as a major element of functionality, and the management of software-intensive weapon systems no longer represents the kind of arcane, low-level, technology-focused task that has so often been relegated to functional specialists working in isolation. Indeed, as software design and integration are now explicitly addressed from the earliest stages of system engineering, software acquisition is becoming a core competency for the program manager (PM), contracting officer (KO), systems engineer, logistician and other critical roles in the acquisition process. Moreover, the kind of embedded software found in aircraft, missiles and like real-time applications represents some of the most technically-challenging software to develop, maintain and support.
Unfortunately, our record in terms of software acquisition has been spectacular, marked consistently and pervasively by spectacular cost overruns, schedule breaches and performance shortfalls so severe that a disturbing number of software-intensive systems have been delivered without meeting specification, unable to fully perform the intended operational mission, or worse, either canceled in the testing phase (i.e., after the expenditure of most development funds) or rendered to sit unused as shelfware or "dead code" functionality.
Further, software is now acknowledged as sitting on the critical path of most major weapon systems and is widely regarded as the highest-risk element in an acquisition. Coupling this high risk with ever-increasing software functionality and pervasiveness through weapon system programs, the "software dragon" can no longer be slain (DSMC 1996); metaphorically that is, the dragon is growing ever more powerful and is here to stay. In contemplating the wisdom of an ancient Chinese proverb, we must instead strive to harness the dragon and manage software with even greater knowledge, foresight, determination, vigilance and flexibility than are now applied to the acquisition of high-risk hardware, electronics, system integration, training and post-deployment support activities.
This instructional case is designed to help prepare acquisition students for some of the unique demands and skills required to effectively manage software-intensive weapon system programs through examination of the Joint Stand-Off Weapon (JSOW) acquisition process. Specifically, this case documents, critiques and generalizes the JSOW's logical extension of the integrated product team (IPT) approach to integrate technical planning and development on a program with the periodic requirements to contract for each phase of weapon system design, test and production. The key is, rather than interrupting IPT-based software engineering and management (i.e., technical planning/development) to cycle through each fiscal year's contracting process (i.e., contractual planning/negotiation), the JSOW program team has effectively learned to integrate contracting into the technical work through an innovative adaptation of the acquisition reform initiative commonly referred to as "alpha contracting."
Further, because this tactical weapon system program combines both hardware and software, both development and production, both Navy and Air Force, and both a baseline configuration and variants, the lessons to be learned from this case are in no way limited to just software acquisition nor to just missile systems; rather, the JSOW case represents an elucidating exemplar, both for direct study and generalization across a wide variety of software-intensive and non-intensive programs likely to be encountered by acquisition students today, and almost assuredly encountered by future acquisition managers, executives and policy makers.
Subsequent to this software-specific introduction,
the case is organized as follows. The background information pertaining
to the JSOW system and program are first discussed to provide
a context for the experience and innovation highlighted through
the case. This discussion is followed by a general description
of the baseline contracting process that is practiced in most
acquisitions as well as a high-level overview of the alpha contracting
process, which is used to support both comparison and contrast
with the specific JSOW experience presented in the fifth section.
The case then builds upon these process descriptions and JSOW
experience to formulate a rough and preliminary, generalized alpha
contracting model to be used for decision making, and the case
closes with a software-specific conclusion, augmented by some
key references and appendix items.
JSOW BACKGROUND
The JSOW is an autonomous, air-launched glide weapon designed to attack a variety of ground targets from standoff range. The term JSOW is actually used to represent a family of air vehicles that share a common platform and variants with unique missions and payloads. The JSOW is a joint U.S. Navy (USN) and Air Force (USAF) program with the USN as lead. Weapon-system integration is ongoing for several aircraft, including the F/A-18, F-16, B-2, B-52 and planned for a host of others in the current and future inventories.
The current JSOW program emerged from the Advanced Interdiction Weapon System (AIWS), a Navy program initiated in the mid-Eighties. The Operational Requirements of the time indicated a vital deficiency to be satisfied by AIWS that would be developed to accompany advanced strike and other new weapon system starts. Following the Tri-Service Standoff Attack Missile (TSSAM) program cancellation in the early Nineties, JSOW program affordability was identified as, and continues to represent, a critical program element, and the JSOW is being aggressively managed within a strict average unit-cost threshold that was established early in the program. Unlike some historical DoD programs that have simply used the "affordability" label to satisfy critics, the JSOW affordability goals have driven a number of key design and production decisions (e.g., aero-efficient structure, low-cost guidance & electronics unit, low-cost control section), and they continue to drive difficult choices for the program (e.g., tooling for efficient, high-rate production despite near-term funding shortages).
Indeed, the JSOW, along with the Joint Direct Attack Munition (JDAM), is part of a high-level "neckdown" strategy for the military, which is conceived to reduce and integrate a number of different air-launched (and -dropped) weapon systems in the arsenal. Two major forces behind this strategy involve the improved utilization of scarce magazine space aboard carriers (i.e., not having to store so many, different types of weapons for carrier aircraft) and simplified training requirements for aircraft and ordnance technicians (i.e., not having to learn the use and service of so many, different types of weapons for aircraft). High reliability along with all-up-round (AUR) packaging and built-in test (BIT) capabilities also support excellent availability and rapid mission-preparation goals.
Required mission capabilities for standoff launch range, day/night/adverse-weather operation, autonomous interdiction, in-flight navigation, terminal guidance, high kill probability, robust availability and other key performance parameters (KPPs) make the JSOW design a significant challenge, particularly with respect to its aggressive and strict cost goals. In fact, early estimates suggested that cost for such a weapon system would be several times higher than the established program goals, in order to achieve the full planned functionality and efficacy (i.e., satisfy the KPPs). This persistent and difficult focus on affordability has driven the program down a path of aggressive and progressive acquisition strategy and execution, which has involved a combination of competition and cooperation.
At first glance, the ideals of competition and cooperation may appear to be incompatible, but the program has maintained a positive balance between the two. For example, competition played a key role in the early phases of the JSOW strategy, dating all the way back to the early AIWS years, but so has a spirit of openness and partnership between the program office(s) and industry. From its inception, multiple contractors have been solicited, consulted and actively encouraged to participate in formulating and shaping the AIWS/JSOW program, and the government has remained very open to contractor ideas and perspectives, pertaining to affordability as well as technical design. On several occasions, contractor responses to government requests for information (RFIs) served to confirm program office expectations (e.g., that mission and performance parameters were feasible) as well as fears (esp. that the unit cost would be high). Further, well before "acquisition reform" came into vogue, the JSOW team was concentrating on systems performance specifications in lieu of detailed design "specs," and encouraging contractors to provide innovative approaches and solutions to problems, technical and affordability alike. For example, several of the contractors responding to RFIs proposed the current aerodynamically-efficient glide weapon (i.e., engineless system) design to reduce cost while still meeting standoff mission requirements.
The competitive aspect of the JSOW acquisition intensified as three Demonstration and Validation (Dem/Val) Phase contracts were awarded to contractor teams in June 1989. The results of this Dem/Val phase allowed the Government team to gain considerable insight into the technical, management and cost risks associated with the design conceived by each of the contractor teams, as well as several design and programmatic approaches to combining weapon system affordability with operational performance. Source selection, conducted by the Government team for the Engineering and Manufacturing Development (EMD) phase contract, resulted in a successful Defense Acquisition Board (DAB) review in June 1992, and thus the issuance of the Milestone II Acquisition Decision Memorandum (ADM) which authorized the program to begin EMD. The Dem/Val contracting activities also emphasized competition between multiple contractors. The source selection, which focused on outyear costs as well as the immediate EMD contract, resulted in a contract awarded to Raytheon TI Systems (RTIS) for $188M to develop the Baseline (BLU-97) JSOW in June 1992. At this point, despite the downselection to a single contractor, the government retained competition as a primary objective; it required the contractor to generate and deliver a technical data package (TDP) with product-level drawings that can be used to develop a second source, for example. As the EMD work progressed, two factors worked in concert to alter the government position on developing a second source: 1) the growing complexity of the JSOW system and its variants, and 2) the competition study.
Regarding the first factor, as work on the BLU-97 dispenser weapon system accelerated, advance activities associated with the pre-planned product improvement (P3I) version (now referred to as the Unitary variant) intensified, which required increasingly-close government-contractor coordination. Once the USAF became involved with a third variant, BLU-108, the government team also required augmented coordination between the Navy and Air Force program management offices (PMOs), particularly as the Navy technical support was being managed from the Naval Air Warfare Center, Weapons Division (NAWCWD) at China Lake, California and the Air Force technical support was centered across the continent at Eglin AFB, Florida. As a step toward simplification and streamlining, the Navy team at China Lake took the technical lead on the BLU-97 weapon system, the primary integration of which was planned for the Navy F/A-18. Likewise, the Air Force team at Eglin took the lead on the BLU-108 variant, the primary integration of which was planned for the F-16. The Navy team also took the technical lead on the Unitary variant. Despite this separation between technical leads, however, it is important to recall that the variants share a high degree of commonality (e.g., common airframe , avionics, mission flight profile, others), will be produced on a single production line and are managed jointly as a combined USN/USAF program. With this multiplicative level of coordination between variants, services and contractor organizations, second sourcing would have exacerbated an already complex arrangement that appeared to be working well.
At the same time, moreover, the JSOW project office commissioned a competition study, which showed that the PMO retained considerable flexibility over the timing of any dual-sourcing decision it may choose to make; that is, savings from competition at the prime-contractor level could be attained well into the full-rate production (FRP) phase of the program, indicating that the government could continue to effect contractor efficiencies through the option of competition for several years, thereby deferring the need to further complicate the existing network of JSOW variants and acquisition participants. Indeed, the contractor was made well aware of the results and implications of this competition study, and it participated actively in the aggressive cost-reduction initiatives that continue to the date of this writing. As the result of these and other factors, enhanced by a relatively short cycle time (under five years from Milestone II through operational flight test) for development and a successful test program, the JSOW received DAB approval to enter low-rate initial production (LRIP) for the BLU-97 Baseline well in advance of completing its total flight test program (i.e., testing the BLU-108 and Unitary variants). Based on these factors, a single source was retained for production.
As the acquisition reform wave then swept through the DoD PMOs, the JSOW program began to rethink many of its acquisition concepts. For example, despite the emphasis on performance noted above in the context of the concept-exploration and Dem/Val phases, the EMD contract was originally laden with a full complement of MIL-SPECs and MIL-STDs. Also, notwithstanding the close technical coordination noted above in connection with EMD, contracting was accomplished via a notably pre-reform process; this "baseline" contracting process is described in the following section to enhance both comparison and contrast with the focus of this case on alpha contracting.
Well into EMD, in anticipation of some major technical
changes to the weapon system design(s), a number of acquisition
reform initiatives were set into motion on JSOW. For example,
MIL-SPECs and MIL-STDs were reduced dramatically (NARO 1997),
as was the number of required data items required by the government,
and many other reforms were effected. Somewhere around this same
time the contracting process also began to change, as the effective
IPT concept was extended to address the contracting process in
addition to the ongoing program-management and technical activities.
By the time that alpha contracting was formally employed
for Unitary procurement, the RTIS-PMO team had already set into
motion a number of effective process steps to ensure its success;
more importantly, perhaps, the teams had already learned
to trust one another and were learning to solve problems
together on a daily basis. This learning and the receptivity of
both the government PMO and contractor are deemed by program leaders
to represent key elements of alpha contracting efficacy on JSOW.
BASELINE CONTRACTING PROCESS
As noted above, the baseline (i.e., pre-reform) contracting process is described here to enhance both comparison and contrast with alpha contracting. This approach is consistent with the specification of an "as is" (i.e., baseline) process model in most business process reengineering (BPR) projects or other engagements involving radical change (ARQ 1998); as we shall see, the transition to alpha contracting represents a radical change indeed.
The focus of this study is initially on a very common
but special case of acquisition contracting: contracting by negotiation
(as described in FAR Part 15), as applicable to most major weapon
systems (i.e., ACAT I programs). This initial focus provides a
clear frame of reference for effective comparison and contrast
with the alpha contracting approach and it corresponds to the
class of acquisitions that are the most-complex and time-consuming:
major weapon systems. Further, although alpha contracting is commonly
applied to sole-source procurements today (including JSOW), the
model certainly does not exclude competitive procurements, and
our process representation is constructed so as to preserve the
kind of generality and broad applicability that we desire for
a case study such as this. In essence, the various classes
of acquisitions (e.g., sole-source procurements, simplified and
commercial acquisitions, etc.) simply represent special cases
and refinements of this general model.
Figure 1 Baseline Contracting
Process Flow
The basic contracting process flow is delineated in Figure 1. The activities performed by the government PMO team are listed as linked activities under the "Government" column heading and those performed by a prospective contractor are listed in like fashion under the "Contractor" heading; those activities that are performed jointly are listed in the center column to indicate the cooperative/collaborative nature of the activities. "Other" activities such as a DCAA audit, independent government analysis, source selection (if applicable) and the like are not shown in order to avoid cluttering the principal process flow. This process notation combines aspects of the DoD standard Integrated Definition (IDEF) with the "swimlanes" (marked by dotted vertical lines) that have emerged as a common modeling practice used by consultants (cf. Rummler and Brache 1991). Our general process baseline represents a composite view synthesized from several sources (e.g., FAR Parts 7 and 15, Arnavas and Ruberry 1994, Hearn 1996, Nissen 1996, 1997) and years of personal experience and conversations. Clearly, this general process description also captures and highlights the key elements of the baseline alpha contracting process for JSOW.
For purpose of comparison and contrast between this baseline process and its alpha counterpart, we choose to begin the process description with the preparation of a statement of work (SOW) for prospective solicitation and contract (labeled "Prep SOW" in the figure). Understanding that a great many acquisition steps must be taken before this activity begins (e.g., preparation and approval of the Mission Needs Statement (MNS), Operational Requirements Document (ORD), numerous other DAB documents, and preparation of system performance or design specifications, work breakdown structure, PPBS support, requests for information, pre-solicitation conferences, others), the process activity associated with the beginning of a particular contracting cycle corresponds to a formal description of the work (or objectives) for which a solicitation and contract are contemplated; this is the SOW and it generally involves the coordinated input from technical personnel (e.g., system engineers, design engineers, manufacturing engineers, logistics engineers, software engineers, etc.) in a government PMO. The SOW, if extensive, is an extension (usually identified as an attachment) of Section C of the Request for Proposal (RFP) using the uniform contract format.
In the next step (labeled "Draft RFP" in the figure), the other major RFP sections are composed, generally by the technical team and one or more Contract Specialists. Much of the documentation required to develop and approve an RFP is straightforward and perfunctory (e.g., justification and approval for sole source (if applicable), standard contract clauses, determinations and findings), once the acquisition strategy and technical scope are well understood by the contracting team. The draft RFP is generally reviewed by the Contracting Officer (KO), the Legal Department and the Program Manager (PM) as a minimum; many other PMO participants (e.g., Technical, Logistics, Cost Analysts) generally also provide input and feedback pertaining to the draft. The first (i.e., topmost) feedback loop (delineated by dashed lines and arrows) denotes a quality and decision step at which the draft RFP (and SOW) is frequently remanded for rework one or more times before final approval.
With an approved RFP, the government is required to synopsize the prospective contract in the Commerce Business Daily or other authorized vehicle for disseminating information pertaining to the procurement. Assuming for sake of comparison that this synopsis represents the first notice of a procurement received by the prospective contractor(s), the interested firm(s) would formally express interest to the government, which earns a place on the list of prospective offerors to receive a copy of the solicitation in the mail (labeled "Mail RFP" in the figure). Assuming also that the prospective contractor(s) have not had the opportunity to review and comment on the RFP in draft form, (in a competitive or pre-reform scenario this is often the case) the RFP (which includes a SOW) is evaluated by the offeror(s) who formally submit(s) any questions that arise in conjunction with the solicitation, work scope or other factors. Once these questions have been effectively answered (notice the quality/feedback loop at this step as well), the prospective contractor then coordinates an internal team of personnel from technical, contracts, pricing and other functional departments to develop a formal proposal in response to the solicitation, which is generally mailed to the government. Any contractor-proposed changes that the government finds acceptable are incorporated into a revised RFP and made available to all prospective contractors.
The government team then evaluates each contractor's proposal, generally using the same people noted above who were involved in preparing the SOW/RFP. As a general rule, the technical personnel who developed the SOW will be tasked to evaluate the offeror's technical proposal, a management team will evaluate the management section and the contracts and cost analysis people will share the evaluation of the price proposal. Not shown in the figure is the formal exchange of government questions and offeror responses that generally accompany this evaluation stage, but a quality/feedback loop appears at this step to delineate another key point in the process at which rework and revision often occur. Also not shown (for clarity of the figure) are the independent audits, analyses and estimates that are often performed by government agencies outside the PMO (e.g., DCAA, ICA, etc.).
For a sole-source, negotiated procurement, the evaluation step is followed by formal fact-finding and discussions, where the government team will generally travel to the offeror's plant location to review the technical details and basis of estimates that support the proposal; this is the case with JSOW. Although plant visits and proposal discussions may also take place in competitive procurements, this step generally marks the beginning of the bargaining stage in a negotiated procurement.
At this point in the acquisition process, by contrast, the steps involved with a competitive procurement would diverge considerably from those associated with its sole-source counterpart, as a cumbersome and time-consuming sequence of source-selection activities are simply bypassed in a non-competitive procurement. Whether a sole-source or competitive procurement, however, such discussions provide the government with an opportunity to advise the offeror(s) of notable omissions or deficiencies that are perceived in conjunction with the proposal(s), and the offeror(s) generally take(s) the opportunity to revise and resubmit the proposal(s) on the basis of these discussions; this is reflected by the two feedback loops emanating from the factfinding step. Notice, in the baseline process flow, that this step represents the first activity in which the government and contractor personnel work jointly toward the end product: a definitized contract for award.
Once fact-finding and discussions (and one or more proposal revisions/resubmittals) are complete, both the government and the offeror are generally required to meet with their respective upper-level management personnel to obtain authorization to begin formal contract negotiations. This process activity is termed pre-negotiation business clearance in the government and a host of similar names in industry (labeled "negotiation targets" in the figure).
Clearly the formal negotiation activity that follows involves joint participation, as face-to-face, team sessions represent the norm. Although only the KO is authorized to formally conduct contract negotiations, he or she will generally employ the support of technical, cost and other personnel from the PMO team. Particularly in the case of large contractors, the Contracts Manager (i.e., KO counterpart) will do likewise. Negotiations are customarily conducted at the customer's (i.e., government PMO) office location and sessions associated with complex products and services are known to last for months. As a joint, synchronous activity, this process step is both expensive and time-consuming to conduct, as a relatively large group of high-level program personnel from both the government and contractor teams are required to travel, dedicate time and participate in sessions that are often detailed, tedious and confrontational.
To complete this characterization of the baseline
process, once negotiations are complete, with a meeting of the
minds between the government and contractor, the government team
generally must obtain a post-negotiation business clearance before
awarding the contract. Most contractors have a similar step required
to ensure home office approval of any deal that is made by the
negotiation team. With this, the sole-source and competitive-procurement
process flows would reunite, as the government announces formal
award of the contract and the (winning) contractor prepares its
internal work and budgeting systems to perform on the new contract,
along with the necessary cost/schedule control system documentation
that may be required. Although basic contract administration and
many "contracting" activities continue well beyond this
point, including the debriefing of unsuccessful offerors and addressing
any protest(s) that may be submitted, for our purpose of comparison
and contrast with the alpha contracting process, this process
model and description provide the necessary grist for understanding
and communicating the key process activities, personnel and sequencing.
This description and corresponding figure are collectively referred
to what we term the baseline contracting process.
ALPHA CONTRACTING PROCESS
The alpha contracting process is described in this
section to setup and support both comparison and contrast with
the baseline contracting process outlined above. Using the same
process notation, the alpha contracting process is delineated
in Figure 2. Notice, at first glance, how the overall pattern
of the process flow differs considerably from that pertaining
to the baseline contracting process presented above (esp. in terms
of process length, simplicity and collaboration), and take note
that this latter, alpha version of the process accomplishes all
of the same results required by its baseline counterpart above.
Notice too that this alpha contracting process description also
represents a general model of the process, as opposed to
a specific delineation of any particular instance; this is consistent
with the baseline model presented above and serves to support
relevant comparison and contrast. As above, it is entirely consistent
with the specific alpha contracting process put into place
for the JSOW program. Like the baseline, this general alpha process
model represents a composite view synthesized from several sources
(e.g., CTEX 1997, Drewes 1996, JSOW 1997, Meyer 1997, TACOM 1997)
and personal experience and conversations.
Figure 2 Alpha Contracting
Process Flow
As with the baseline contracting process above, alpha contracting also begins with SOW preparation, which precedes the composition of a draft RFP. As noted above, the underlying steps are the same. The principal difference is denoted by the placement of these activities in the center column of Figure 2 (i.e., the "Joint" column in between those setup for the Government and Contractor) to indicate that these activities may be performed jointly by the government and contractor teams, once an acquisition strategy and plan (often including a preliminary RFP) have been developed by the government; that is, technical personnel from both the government PMO and contractor organization work together to develop the draft SOW, as do contracts and pricing/estimating personnel to develop the draft RFP. Instead of iteratively trying to accomplish these tasks "at arms length", and mailing formal documents back and forth, as above in the process baseline, the IPT approach is employed to jointly develop these key documents.
This approach can be described in terms of an investment; both teams invest the time and attention of key personnel up-front to jointly develop these key contracting documents, with the objectives of: 1) improving communications; 2) decreasing the number of formal RFP iterations, revisions and rework required to correct misunderstandings, errors and mistakes; 3) reducing the cycle time (procurement administrative lead time or PALT) required for contracting; 4) increasing the level of trust, openness and mutual respect between the government and contractor teams; and 5) decreasing the overall cost, both for the government and contractor, associated with the procurement.
When the draft SOW and RFP reach a state of "completion" that is agreeable to representatives from both the government and contractor teams, the RFP document goes through essentially the same government approval process described above for the baseline. The prospective contractor(s) may have a similar approval process with upper-level management, legal staff and others to validate that the team members' work adequately reflects the interests and objectives of management. Notice the quality/feedback loops from above recur here in the alpha contracting process as well; through dynamic modeling and simulation, we would expect for such feedback loops to be traversed less frequently than in the serial process flow delineated above for baseline contracting. Indeed, as with the application of IPTs to other processes, the idea is to de-linearize process flows through the joint, cross-functional participation of all, key, interested parties.
Continuing the IPT theme, notice that the "develop proposal(s)" activity is also accomplished jointly; that is, the same people, both government and contractor, who collaborate to develop the SOW and RFP together will continue their collaboration to transform this SOW/RFP document, through a contractor proposal, and make it the contract. Toward this end, technical representatives from both the government and contractor organizations will work together to understand requirements, articulate and refine the contractor's technical approach, and perform tradeoff analyses between factors of importance such as cost (as an independent variable), schedule, quality, performance and others. Similarly, cost/pricing representatives from both organizations will work together to understand requirements, develop and refine the contractor's basis of cost estimates, and support the aforementioned tradeoff analyses. Likewise, contracts and program office representatives from both teams will work together to understand requirements, develop and refine the programmatic groundrules and assumptions used for cost estimating, and collaboratively compose the contractual language (i.e., terms and conditions) appropriate to balance the risks, rights and responsibilities associated with the corresponding technical approach and cost estimates. Feedback to both the government and contractor activities accompanies this key process step.
As above, this process proceeds through the business clearance/negotiation targets steps, but notice that the fact-finding and discussion activities are absent from the alpha contracting process model diagrammed in Figure 2. The point is that the collaborative nature of the preceding process activities (esp. SOW/RFP preparation and proposal development) obviate the need to conduct fact-finding and discussions; that is, in the alpha contracting process, these "steps" take place concurrently with the development of the RFP and proposal, as opposed to a series of subsequent and separate activities. This concurrency contributes considerably to the shorter process length that is observable by comparing the two figures, which implies a reduction in cycle time for the process.
After the negotiation clearances are obtained, the
formal negotiation would proceed as before, in theory, with the
two sides achieving a meeting of the minds on the contractual
scope, price and language for the acquisition. The key difference
is that, at some point, the "collaborative" nature of
the activities represented above has the potential to breakdown.
Negotiation represents a stressful activity which often reduces
to a zero sum game, and hence collaboration may give way to confrontation,
even before the formal negotiation step has been reached.
We will return to this point, but note here that such confrontation
has the potential to negate many of the key, trust-based advantages
of the alpha contracting process, particularly as the same individuals
are expected to jointly collaborate again for the next fiscal
year's procurement.
JSOW EXPERIENCE
As noted above, management of the JSOW program has
required the deft integration of demanding performance and cost
objectives, and it has been executed through a delicate balance
between competition and cooperation. A number of factors make
the JSOW alpha contracting process unique, but the process is
entirely consistent with our general, alpha contracting process
model presented above and none of the principles, tools or techniques
described in this section are restricted to just the JSOW program;
that is, the JSOW experience is broadly applicable to a wide variety
of different programs, systems and contracting situations. We
address the broad generalization of the JSOW experience through
the Alpha Contracting Model presented in the subsequent section.
In this section, we first outline some of the key contextual factors
associated with the JSOW program and then proceed to describe
five of the most noteworthy innovations made by the JSOW team
in its planning and execution of the alpha contracting process:
1) Thermometer Chart, 2) Change Boards, 3) Proposal Web Site,
4) Management Oversight Panel, and 5) Organizational Learning.
We close by summarizing the key benefits realized by JSOW through
alpha contracting.
Contextual Factors
As noted above, at the time of this writing, the program has progressed very successfully through the EMD contract for development of the Baseline (BLU-97) vehicle, and it is currently executing an LRIP Lot 1 contract for BLU-97 while in the midst of contracting for its second LRIP lot. Also noted above is the fact that JSOW contracting has not involved competitive procurement since the EMD award to RTIS; this is the primary reason for our emphasis on the sole-source aspects of the baseline and alpha contracting process descriptions above. Not noted above is the fact that the program elected to make a change in contract type for the current contracting cycle; whereas the EMD and LRIP Lot 1 contracts were and are executed on a cost-reimbursement type contract (LRIP Lot 1 was originally priced as an EMD contract option), a fixed-price incentive (FPI) contract is contemplated for LRIP Lot 2. As the reader is undoubtedly well aware, this change in contract type effects a substantial transfer of risk from the government to the contractor and can produce a shift in the relative degree of cooperation versus confrontation experienced in alpha contracting. We also noted above that the JSOW is categorized as an ACAT ID (i.e., major) DoD program and represents a complex, software-intensive weapon system that has not yet completed its operational flight test activities for all weapon system variants (i.e., BLU-108 and Unitary); these contextual factors may play an important role in decision making about alpha contracting.
The geographical separation between government project
offices (USN in California and USAF in Florida) and the contractor
(RTIS in Texas) serve to exacerbate the upfront time and personnel
commitments required for alpha contracting; that is, not only
must a number of high-value personnel from the government PMOs
and contractor team invest a substantial amount of time in conducting
the many, often-lengthy joint activities required to develop the
technical, cost and contractual details associated with a solicitation,
but the government teams are required to travel to the contractor
plant location for the equivalent of several weeks, year after
year. Thus, having noted above that the alpha contracting process
in general is expensive and time consuming, we find that the geographic
separation between the contractor and government PMOs compounds
the costs and difficulties associated with joint proposal/contract
development; and, although both the government and contractor
teams appear to be learning and improving the process from year
to year, the current process continues to place heavy demands
on the resources of both teams.
Thermometer Chart
The JSOW PMO team has developed a number of innovative techniques for managing the alpha contracting process. One technique involves the use of a "thermometer chart" to depict SOW scope items that are negotiable and to differentiate them from elements that are categorized as "must haves" for the government. Figure 3 is presented to illustrate the general use of this graphical technique. The vertical scale represents SOW scope that has been priced in dollars as (jointly developed and) proposed by the contractor. The bottom area represents scope that has been designated "off limits" in negotiation; in this case, the government is required by law to procure a certain quantity of LRIP missiles and the quantity of this fiscal year buy is non-negotiable. In an EMD contract, this technique could be used for areas of technical scope that correspond directly to the KPPs for a program; that is, technical and other thresholds that must be met for the program itself to remain viable. This bottom area is colored red in the original thermometer chart.
Figure 3 Thermometer Chart
Similarly at the other end of the "thermometer," the top area is also colored red in the original and represents a challenge for the program to achieve its unit-cost objectives. In this context, for the program to achieve an average unit cost below its threshold/objective, the contractor will be required to follow a cost-improvement curve (i.e., learning curve) that is steeper (i.e., faster rate of improvement) than the one proposed for the LRIP Lot 1contract. In other words, if the contractor's proposal reflects the "true" improvement curve for the program, then the JSOW unit-cost target is unlikely to be met. Thus, the government and contractor are challenged to manage the program to ensure affordability; we noted above that this has involved design changes, the purchase of special tooling and test equipment, planning for a higher (i.e., more efficient) production rate and a host of other decisions and activities (e.g., design to cost) that help lower production cost. The "warranty" section of the thermometer is colored yellow to indicate that it is non-negotiable in terms of its existence (i.e., the production program will have a warranty provision), yet both the government and contractor remain flexible at this point in terms of crafting the most cost-effective warranty possible.
The middle area depicted in Figure 3 is colored green
in the original thermometer chart and represents the scope items
that are targeted for joint review. Although some kind of scope
prioritization and partitioning takes place on most programs and
contracts, the graphical technique and thermometer metaphor employed
by the JSOW team have proven to be particularly effective in terms
of communication. Clearly from the chart illustrated in Figure
3, the ("green") scope items depicted in the middle
area (e.g., support engineering, data, program management) serve
to focus the attention and efforts of program personnel on the
work that offers the best opportunity for refinement and change.
A great many programs and contracts have been witness to effort
wasted on proposing scope changes that are unacceptable to the
government. Using this technique, the JSOW team has learned to
address this issue early in the contracting process and
to highlight areas of disconnect and disagreement at the beginning
of the contracting cycle.
Change Boards
Another area of innovation observable on the JSOW program involves the application of engineering-style control over the alpha contracting process. Although the technique itself stems directly from the same configuration management (CM) process involved with the engineering development of any complex weapon system such as the JSOW, the application of this CM technique to the contracting process is unique and it has proven to be very effective. As a brief refresher on technical CM, when a weapon system is being developed (i.e., during EMD) and later produced, the system is defined in terms of a baseline configuration that is clearly articulated and widely disseminated. Once the baseline configuration has been defined, the key to this process involves the control over changes to the missile design. One well-intentioned structural change to a section of the missile (e.g., that changes the outer mold line) may have unintentional consequences in one or more other areas (e.g., aerodynamics, observability) that are beyond the purview of the structural engineer. To guard against such inadvertent consequences, nearly every well-managed engineering organization institutes a Change Control Board (CCB) to review and approve every change to the baseline configuration. The CCB is generally comprised of an inter-disciplinary set of representatives from every functional area who meet periodically to jointly review proposed changes and prevent their unintended side effects.
The application of this CM technique to the contracting process is similar in terms of objectives and procedures. The fundamental difference is that the "configuration" to be baselined and controlled pertains not to a missile, software system or other technical design; rather, the baseline to be controlled is the RFP, which later evolves to become the final contract. In other words, once the draft RFP has reached a state at which the government and contractor agree that it is representative of their goals and intentions for the program, they create and disseminate a baseline, and then require any subsequent changes to be approved by a contractual variant of the CCB, "Contract Control Board" in this case. Anyone, PM, KO, Systems Engineer, Cost Analyst, contractor, etc., wanting to make a change to the RFP/contract must submit a request and obtain approval from the joint CCB before the change is implemented into the baselined RFP. The updated RFP is then made available to all concerned. This process ensures two things: 1) all concerned parties are viewing and reviewing the same version of the RFP, and 2) the alpha team always has the most current RFP from which they prepare their proposal.
A basic study of group dynamics indicates that the membership of this CCB group represents a key determinant of its feasibility and ultimate success. If the group gets to be too large, scheduling becomes a key concern and the board may be unable to meet often enough to support the dynamics of a short cycle-time alpha contracting process; alternatively, the fewer the representatives, the more likely it becomes that a well-intentioned change will have an inadvertent impact on some function or discipline that is not represented on the board. Clearly both the government and contractor should be represented on this board, for in the joint process of developing the SOW, RFP, proposal and contract, people from both organizations share the responsibility for composing, reviewing and coordinating these complex and dynamic contractual documents.
In the case of the JSOW team, the CCB is comprised
of five primary members and supported by several others on a case-by-case
basis. This primary membership includes the government deputy
program manager (along with the offeror's PM), KO (along with
the offeror's Contract Manager) and a government CM specialist
dedicated to managing the RFP configuration itself. Other
attendees include system engineers, cost analysts, contract specialists,
manufacturing engineers, logisticians and others involved parties.
The individual that requests a particular change will always be
invited (i.e., required) to attend the CCB session in which his
or her request is discussed. This approach serves to keep the
group small for purpose of schedulability, yet it remains open
to a wide diversity of participants to help ensure that no area
is neglected nor input overlooked. Where an error in size may
be present in terms of board membership, the team would prefer
to err on the side of having too many attendees who sit quietly
through the CCB as opposed to having too few and making problematic
changes that either require rework or go unnoticed until after
contract award. A flowchart depicting the basic CCB process is
delineated in Figure 4.
Figure 4 Change Process
Similar to the CCB, which is used to control the RFP/contract, a complementary group called the Proposal Change Board (PCB) performs a comparable task for the proposal as it is being developed. As with the CCB process, once the contractor proposal has reached a state at which team members are generally satisfied, it is baselined just like the RFP and any changes thereto must be requested in advance and approved by the PCB. The membership of the PCB is essentially the same as that of the CCB and they follow a similar procedure. The key difference is that the objects of discussion in the PCB are the estimated costs and basis of estimates that are proposed by the contractor, whereas the corresponding CCB objects are the non-price elements of the RFP (e.g., SOW, CDRLs, quantities, clauses, etc.). This process technique effectively integrates aspects of proposal development, fact-finding, negotiation and CM together to enhance the team's ability to identify problem areas early in the procurement cycle and to jointly develop cost estimates, an activity that can become contentious and confrontational.
Again using color-coded communication media, the PCB process involves a cost account matrix (i.e., where each WBS element intersects with a functional organization) that has a representative from both the government and contractor assigned to manage its cost development. When the process begins, every cost account is colored red to indicate that neither scope nor cost have been agreed to by the joint cost account managers. As joint work progresses, generally the government and contractor representatives will agree first on the desired scope of the effort (i.e., the SOW), at which point the cost account is changed to show yellow in the matrix. When the joint representatives then agree on the cost estimate for that SOW effort, it changes in turn to green. Final approval by senior management earns a cost account a blue rating. Clearly, as the process iterates and scope is sometimes revised to accommodate cost, one or more of these cost accounts may actually cycle from red to yellow to green and back to red, but the color-coded scheme enables managers from both teams to quickly assess the status of the alpha process. Moreover, the cost account scheme places the responsibility for joint agreement squarely on the shoulders of the people who are best qualified to discuss the relevant issues: the cost account managers. The PCB can use this color scheme to identify those areas that appear to need the most "help" in reaching some kind of consensus.
However, consensus cannot always be reached, and
the probability of reaching consensus on every cost account is
inversely proportional to the budget pressure faced by the PMO
for any particular proposal/contract; when the program is operating
in a sole-source mode and the contemplated contract is of the
fixed-price variety, this probability of consensus decreases even
more dramatically. Therefore, the JSOW team uses another technique
called "risk/lift" to help reach consensus. The idea
is this; when an impasse is reached on a particular cost account,
say that the government and contractor simply cannot agree on
a manning level, support-labor percentage, improvement-curve slope
or other cost-estimating parameter, the team will use one estimate
or the other (generally the government's) and denote the delta
cost as an area of "risk" or "lift" to the
contract. This enables the working-level participants to proceed
on to other areas, while earmarking those of some contention to
be addressed later. Although on the surface this may appear to
represent little more than semantics and perception-management,
it allows the process to proceed even when difficult obstacles
are encountered. This technique can facilitate a significant benefit
in terms of cycle time for the contracting process.
Proposal Web Site
With the proliferation of Internet users on the World Wide Web (Web), businesses and consumers alike are able to compose and exchange a variety of documents hosted on heterogeneous computer hardware and software platforms (e.g., PCs, Macs, UNIX workstations). The JSOW program team has taken advantage of this resource and setup a Web site to host, along with other JSOW information, all of the key documents pertaining to the contracting process (JSOW Site 1997). Notwithstanding the considerable travel and face-to-face meetings noted above that are required to ensure an effective alpha contracting process, this secure Web site serves to enhance communications between the geographically distant program sites. Although no classified information is hosted on the site or transmitted via Internet, the Web site is used to publish, review and revise sensitive cost and pricing data (e.g., indirect rates, efficiency factors) that the contractor would not want released to the public; moreover, when considering the use of such Web technology for competitive procurements, the government would also clearly be obligated to protect proprietary designs and technical data furnished by offerors. The security itself is based on a server capability for strong (128-bit key) encryption and access to the site is restricted by password protection.
Browsing through this site, one can quickly become familiar with the program history, peruse existing contracts, RFPs, data items, CCB minutes, proposal estimating groundrules, assumptions and cost summaries, and a host of other program-related documentation. This medium for information dissemination is used from the inception of any contract action and provides an excellent complement to the PCB/CCB controls discussed above; that is, because all official contract documentation is hosted on a single server, revisions to this documentation can be easily controlled through restricted (procedural not technical) access to the Web site.
Take an RFP modification as a case in point. As noted
above, once the (jointly developed) draft RFP has reached a point
at which it is approved for release, it is baselined and placed
under configuration control by the CCB. When someone on the project
team desires to make a change (e.g., alter contract line item
numbers (CLINs), insert a commercial warranty clause, modify the
SOW, WBS, schedule or other document), the initiator submits a
contract change request that must be reviewed and approved by
the CCB prior to implementation of the change. With approval,
the change request is processed by the configuration manager who
makes the approved change(s) to the document(s) hosted on the
Web site. The RFP document is given a change number and the revised
version is then made available to all via the Web site. Through
this online system, the most current proposal and contract information
is always made available for reference and review, so coordination
between the different, geographically-dispersed government and
contractor team members is enhanced, and the CCB process steps
help to ensure that only authorized modifications and changes
make their way into the official documentation. As one would expect,
all team members are also connected via e-mail, which is used
to notify government and contractor personnel alike whenever PCB/CCB
actions result in revisions to the proposal/contract documentation.
A screendump of the top-level JSOW Web Site page is included in
the appendix.
Management Oversight Panel
As implied by the name, the Management Oversight Panel (MOP) represents a management-level group that guides, oversees and assists the various alpha contracting IPT groups and boards discussed above. This management group itself represents an IPT, moreover, being comprised of the senior officers and contractor personnel who are responsible for the JSOW program. On the government side, this includes the program manager who represents the Navy interests in a class of weapon system programs, including, for example, the JDAM and JASSM, in addition to the JSOW family itself, and his Navy deputy who is specifically responsible for the JSOW program. The USAF deputy for JSOW also serves on this management panel, but his geographical separation from the PMO in Washington (PMA-201) makes it more difficult to include him in the day-to-day program management operations. Interestingly, a similar arrangement exists for the two, related USAF-led programs (i.e., JDAM and JASSM), for which the JSOW PM serves as the Navy deputy. An organization chart depicting some of these relations is presented in the appendix.
For the contractor, MOP membership includes program
management personnel who have roughly the same level of JSOW responsibility
within the contractor organization; this level of responsibility
is often tricky to judge, for RTIS plays no part in either of
the JDAM or JASSM, but the senior PM for this contractor is similarly
responsible for some programs beyond the purview of the JSOW PM
(e.g., Javelin). A contractor "deputy" (corporations
rarely use this term or position) for each of the JSOW variants
(i.e., BLU-97, BLU-108 and Unitary) also serves on the MOP. As
with the change boards described above (i.e., the CCB and PCB),
other personnel are often invited to participate in regularly-scheduled
MOP meetings. These invitees include proposal managers (for the
government and contractor), chief engineers (from both sides)
and others with critical insight or expertise to focus on a particular
issue or problem.
Figure 5 Vertical Filter
Interestingly, as depicted in Figure 5, no overlap
exists between the membership of the MOP and alpha contracting
IPTs/boards from above; that is, government and contractor PMO
personnel who are responsible for managing the details of the
alpha contracting process have no direct role on the MOP, and
vice versa. Thus, the MOP effectively acts as a vertical filter
for information, progress and problems that occur at the working
IPT level, which affords the MOP team an ability to manage by
exception and concentrate their joint attention and energy
on the guidance, issues and problems that most require intervention
by officers and executives at their level. Although this setup
creates some (healthy) tension between the MOP and alpha contracting
groups, the key is that both groups operate on the basis of joint
collaboration between the government and contractor. This provides
a stark contrast to the "us versus them" setup that
exists in most contracting processes; as depicted in Figure 6,
this latter setup represents more of a horizontal filter, with
the associated tension between the government and contractor.
Figure 6 Horizontal Filter
When observing the MOP, one quickly notes the same kinds of open, trust-based relationships between the government and contractor that exists on the lower-level, alpha contracting IPTs, and the MOP members truly engage in joint information collection and problem solving. For example, it is not unusual for the contractor PMs to be hearing program information for the first time in the same meetings at which government officers listen to briefings, and the free flow of information goes in both directions. This represents a contrast with the mode of information passing experienced by many programs, in which contractor personnel require explicit approval to share information with the government and everything that is so shared with the "customer" must be thoroughly reviewed by contractor management prior to its release. Compounding the implications of this latter approach in terms of lack of trust and semi-closed information sharing, it simply takes too long to review and refine all important information before sharing it with the other side, and a complex, dynamic program like the JSOW moves far to fast for such a cumbersome and lethargic process.
Continuing with the theme of joint information-sharing and problem-solving, the MOP does not just concentrate its efforts on the alpha contracting process; rather, this joint management team is also actively involved in the technical development of each JSOW variant (participating on the Risk Management Boards, for example), and the group works together to outline, define and refine a joint strategy for the JSOW-family program as a whole. The involvement in all aspects of the JSOW program supports a very effective integration of the technical-development and production processes with their cyclical, alpha contracting counterpart, which must be repeated every fiscal year; this integration is thought to represent an important contributor to JSOW alpha contracting efficacy. The involvement with joint strategy formulation helps to speed the creation of, and agreement on, a coherent strategy for the program that is designed with the goals and objectives of both the government and contractor (e.g., planning for potential foreign military sales).
One final aspect of the MOP deserves mention at this
point in the case, one which is similar in nature to the tension
between collaboration and confrontation that we observe between
the working-level alpha contracting participants for the government
and contractor. Recall that the alpha contracting process appears
to experience some difficulties when tough, contentious issues
must be addressed in advance of the formal contract-negotiation
activities, and that the transition of JSOW to a fixed-price contract
is noted above for exacerbating this tension. This same tension
between problem-solving and negotiation is also discernible at
the MOP level, as one side or the other may appear to (and in
fact may) be taking a position that is unreasonable, uncooperative
or simply a negotiation ploy. As delineated in the process representation
presented above in Figure 2, at some point in the process, management
should expect to call-in the professional contract negotiators
and have them work-out the final bargaining that is required to
close a deal and definitize the contract. We return to this issue
in the next section.
Organizational Learning
This discussion of the JSOW experience with alpha contracting would not be complete without addressing the vital dimension of organizational learning. This dimension is viewed as being especially important by the contract principals (e.g., MOP and permanent PCB/CCB members), for the government and contractor team members feel that they have definitely improved their joint performance and working relationships through the alpha contracting experience that began in the latter stages of the Baseline EMD program. The reason that organizational learning is viewed as playing such an important role in alpha contracting is that the contracting process itself has historically been based on a win/lose philosophy and performed on a confrontational basis; this historical pattern is not unique to the JSOW program. To ask a seasoned contractor to suddenly shift its mental model and trust the government counterpart not to take advantage of free access to their program information, contract books and personnel is not a trivial task; likewise, for the government to abruptly change its thinking and trust the contractor not to capitalize on its budget data, independent analyses and open information sharing requires a cultural change that cannot occur overnight.
Indeed, in the beginning stages of the switch to an alpha contracting approach, the trust-based steps taken by both sides were relatively small and the associated issues addressed jointly were somewhat minor. The important element was that both sides were actively trying to change the culture and working to establish and reinforce trust between the two parties. As these relatively small and minor steps were reinforced, they led progressively to larger trust-based activities and ultimately to the Unitary and Baseline LRIP Lot 1 proposal/contracts, which represent the first JSOW alpha contracting processes performed in their entirety. A number of positive developments and lessons learned from the Unitary and Baseline LRIP Lot 1 contracting cycles then led directly to improvements that were institutionalized in advance of the LRIP Lot 2 process. A summary of some lessons learned is presented in the Appendix.
Another factor to consider in terms of organizational learning and trust-based contracting is that, on the surface, the most important relationships appear to be personal, not organizational; that is, although we refer to the government and contractor organizations as learning to trust one another, the fact is that personal relationships between government and contractor personnel represent the key to trust-based contracting. In other words, the people working on the program must learn to work together and trust one another, and a partial loss of learning (and breakdown of trust) occurs whenever key personnel from either side leave the program. In fact, this phenomenon was experienced by the JSOW program, as the LRIP Lot 1 project directors for both the government and contractor were unavailable (due to retirement and promotion) to manage the LRIP Lot 2 alpha contracting cycle; the government KO was new for LRIP Lot 2; and some other important personnel changes occurred.
Alternatively, much of the organizational learning
that occurs is institutional in nature, and because the program
office leadership at the top had continuity for both the government
and the contractor, this facilitated the acclimation of new program
team members at the working level and helped to preserve much
of the organizational learning from one contracting cycle to the
next. An interesting question thus arises as to what extent this
institutional organizational learning is contingent on
the personal leadership and commitment of the program manager;
this represents an provocative question for study through a longitudinal
design, and the associated issue of program manager's philosophy
and leadership is addressed again in terms of our alpha contracting
model.
Benefits
The JSOW benefits derived from alpha contracting are difficult to quantify. Although the cycle time for the contracting process was shorter through alpha contracting than through the baseline contracting process that came before, the program was also in a more mature stage of development (i.e., LRIP vs. EMD) when alpha contracting was instituted in full. Accordingly, although the government and contractor team members spent less time performing the alpha contracting process than its baseline counterpart, the PMO staffs tend to be relatively fixed in size (i.e., no net cost savings), so that personnel costs that are saved through alpha contracting are simply reinvested in other areas of contracting and program management (e.g., improving the quality and completeness of contract documents, watching program risk items more closely, evaluating additional programmatic options for project planning and execution, providing additional briefings to Congress and others). Thus, the gross cost savings derived from alpha contracting are simply offset by the application of program office talent to solve other problems. Notice, however, that this comment is not intended to reflect a poor, unsatisfactory or undesirable outcome; on the contrary, most program managers would much rather invest their (abundant but) limited time and energy in activities other than a lengthy contracting cycle fraught with arms-length document exchange and rework. It is difficult to measure the quantifiable benefits stemming from such reinvestment of time and energy, however.
Further measurement difficulties arise from other
benefits that include improved quality of the contract documentation
(which benefits contract administrators and program managers downstream
after contract award), increased understanding by team members
of key programmatic, technical and contractual issues that are
surfaced and addressed early in the contracting cycle as opposed
to late in the execution phase, and the professional, trust-based
relationships that are developed in the alpha contracting process,
and which carry over to improve the character of work and atmosphere
of cooperation that follows from contracting on into program execution.
These latter benefits represent important elements of the IPT
process that are sought in modern government-contractor partnerships.
The alpha contracting process appears to help foster such partnership
before the execution phase of the program begins; referring back
to the organizational learning points above, this benefit can
effectively help to move the government-contractor team along
the IPT learning curve through joint participation, coordination
and work in the contracting phase. Although this benefit too is
difficult to quantify, such difficulty neither negates nor in
any way diminishes its importance. As a closing note for this
section, one (anonymous) long-term JSOW program participant summarizes
the alpha contracting benefits as follows: "I believe the
biggest benefit of IPT's, which allow for alpha contracting, is
pride of ownership. All of the team members, government and contractor
alike, hold the success of JSOW as a wondrous accomplishment of
which they are all an important part."
ALPHA CONTRACTING MODEL AND DECISION MAKING
Table I Key Process and Contextual Factors
| Factor | Concept/Definition |
| Competition | Whether competition is required |
| Program phase* | Concept, Risk Reduction, EMD, Production |
| Contract type* | Cost, fixed price, other |
| ACAT designation | ID, IC, II, III, other (including MAIS designators) |
| System class | Aircraft, missile, ship, tank, computer, other |
| Program complexity | Number of interrelated product variants, FMS, coproduction, other factors |
| Geographical separation | Number of different states/countries in which key program personnel are located |
| Alpha experience* | Whether (and extent to which) alpha contracting has been accomplished previously by same team |
| Budget/schedule pressure* | Whether (and extent to which) the program budget and schedule are out of line with proposal values |
| PMO commitment | Whether (and extent to which) the program manager is committed to alpha contracting |
| Contractor openness | Whether (and extent to which) the contractor is committed to alpha contracting and teamwork |
| Technical IPTs | Whether (and extent to which) the team employs IPTs for technical development and/or production |
* denotes expectation of change
Let us begin this section by summarizing some of the key process and contextual factors that we have identified through the preceding sections as potentially important managerial considerations and possible contributors to alpha contracting success in the JSOW case. We will use this summary as the point of departure for generalizing our case-study findings and observations in terms of an alpha contracting model that can be used by PMs and KOs for process design and decision making. The key factors are summarized and defined in Table I. Table II indicates the corresponding JSOW experience in terms of these factors.
As can be observed from the tables, we have identified
a dozen factors associated with the alpha contracting process
that are considered a-priori to represent important contributors
to, or determinants of, success. One can also observe the case-specific
values corresponding to each factor the JSOW and how these values
have changed through the two applicable contracting cycles (i.e.,
in which alpha contracting was employed). This summary provides
us with one possible method for sorting the factors on the basis
of their inherent dynamics; that is, whether the factors are expected
to vary as a program matures or to remain constant through the
life cycle of a particular weapon system. Based solely on our
single JSOW observation, these four variable factors, program
phase, contract type, alpha experience and budget/schedule pressure,
are denoted by asterisks in the table; as a first cut, these comprise
one candidate set of controllable factors about which a PM and/or
KO can make decisions pertaining to each specific program.
Table II JSOW Experience
| Factor | EMD/LRIP Lot 1 Experience | LRIP Lot 2 Experience |
| Competition | Sole source | Sole source |
| Program phase* | EMD/LRIP | LRIP |
| Contract type* | Cost reimbursement | Fixed price |
| ACAT designation | ID | ID |
| System class | Missile | Missile |
| Program complexity | 3 variants | 3 variants |
| Geographical separation | 4 states | 4 states |
| Alpha experience* | No | Yes |
| Budget/schedule pressure* | No | Yes |
| PMO commitment | Yes | Yes |
| Contractor openness | Yes | Yes |
| Technical IPTs | Yes | Yes |
* denotes expectation of change
However, by observation, this candidate set is clearly
incomplete, as factors such as PMO commitment, contractor
openness and technical IPTs are also clearly controllable;
notice that some (e.g., technical IPTs) also require a degree
of cooperation between the government and contractor. Alternatively,
variable factors such as competition, program phase
and budget/schedule pressure are seldom controllable at
the level of the PM; rather, they represent variable conditions
that are imposed through a system or process external to the PMO.
Many programs grow in complexity through the course of time, even
though this factor is marked as "fixed" in the table.
Thus, perhaps a more useful categorization would characterize
these factors in terms of two distinct dimensions: 1) locus of
control (i.e., internal vs. external), and 2) variability (i.e.,
variable vs. fixed). The dozen factors could then be clustered
into four quadrants as shown in Table III.
Table III Dimensions and Clustering of Factors
| Locus of Control | Variable | Fixed |
| Internal: | (Quadrant I) | (Quadrant II) |
| Contract type | Alpha experience | |
| Competition | Technical IPTs | |
| PMO commitment | ||
| External: | (Quadrant IV) | (Quadrant III) |
| Program phase | ACAT | |
| Budget/schedule pressure | System | |
| Contractor openness | Complexity | |
| Geography |
With this, we can produce a rough formalization of our alpha contracting
decision making model from the factors as re-summarized in Figure
7. Despite the author's hesitation to propose or employ such a
simple, two-by-two matrix, these, very preliminary research results
suggest that a four-quadrant model like that diagrammed in the
figure may be useful, at least as a beginning, to characterize
the alpha contracting process in terms of decision making. Each
of the four quadrants may be interpreted roughly as follows: 1)
Quadrant I - recurring PMO decision variables (i.e., same variables
may be revisited on each contracting cycle); 2) Quadrant II -
fixed PMO decision variables (i.e., once decisions are made, these
factors tend to remain fixed); 3) Quadrant III - fixed externally-imposed
contextual factors (i.e., important, but outside PM direct control);
and 4) Quadrant IV - externally-determined variables (i.e., variable,
but not directly within PM direct control). Using the model can
be summarized concisely: design and focus decision making on factors
in quadrants I and II; understand, anticipate and react to factors
in quadrants III and IV. Of course, the critical decision is whether/when
to employ an alpha contracting approach.
Figure 7 Four-Quadrant
Decision Model
Extrapolating from our limited JSOW experience, we propose a very simple scheme for scoring the likelihood of alpha contracting success for a particular program; the reader should understand that this represents a very-preliminary and tentative scheme that should be revisited and refined through additional research to address a number of other programs. To calibrate this model, we have rated the JSOW experience with alpha contracting using a simple binary scale: a) score +1 if a factor contributes to alpha contracting success; b) score -1 if a factor inhibits or is neutral to alpha contracting success. The operationalization required to accomplish such scoring for the JSOW alpha contracting (LRIP Lot 1 and 2) experience is summarized for factors in each quadrant through Table IV.
Notice from the table entries that the LRIP Lot 1
score of four exceeds the LRIP Lot 2 value by four points and
is positive. We may propose a rough interpretation of this
raw and simple scoring scheme as follows: the higher the score,
the greater the likelihood of alpha contracting success, and negative
scores (i.e., below zero) may signal potential problems with the
alpha approach. With this, the likelihood of success for LRIP
Lot 2 could be interpreted as diminished with respect to that
of LRIP Lot 1, and, on the borderline between positive and negative
values, caution may be required when employing the alpha approach
on LRIP Lot 2. We must stress and reemphasize, however, that this
model is very rough, predicated on the experience of only a single
case/data point and that much more research and scoring information
from other programs will be required to validate and calibrate
the model before it should be relied upon for decision making.
Alternatively, in our current environment, in which we effectively
have no model at present, even the tentative and speculative
introduction of this simple scoring scheme may provide insight
to PMs and KOs who are required to make such decisions today.
That is the intent of this section.
Table IV JSOW Alpha Contracting Process Scoring
| Quadrant | Factor | Operationalization | LRIP Lot 1 | LRIP Lot 2 |
| QI: | Contract type | Cost vs. fixed price | +1 | -1 |
| Competition | Sole-source vs. competitive | +1 | +1 | |
| PMO commitment | PM committed vs. ambivalent | +1 | +1 | |
| Q2: | Alpha experience | Previous experience (yes vs. no) | +1 | +1 |
| Technical IPTs | Currently employed (yes vs. no) | +1 | +1 | |
| QIII: | ACAT | ACAT II/III vs. ACAT I | -1 | -1 |
| System | Missile vs. other class | -1 | -1 | |
| Complexity | Simple vs. complex program | -1 | -1 | |
| Geography | Collocated vs. dispersed | -1 | -1 | |
| QIV: | Program phase | Production vs EMD | +1 | +1 |
| Budget/Schedule pressure | Low vs. high | +1 | -1 | |
| Contractor openness | Open vs. closed | +1 | +1 | |
| Total Score: | +4 | 0 |
CONCLUSIONS
We noted in the introduction that software is rapidly becoming one of the most pervasive, important and highest-risk elements of any modern weapon system program. Now it is the exceptional ACAT I program that is not software intensive; hence, we exhort program managers to "harness the dragon" and leverage the power of software to make and sustain the kinds of quantum advances in military war-fighting and support processes required to dramatically improve the cost-effectiveness, responsiveness and adaptability of the military of today and tomorrow. Through its integration with technical planning and development, alpha contracting represents one innovative approach to help streamline, improve and enhance the cumbersome and repetitive contracting process, and as in the JSOW case, many programmatic, technical and financial benefits can accrue through such effective integration of the technical and contracting processes.
To recapitulate, alpha contracting involves the straightforward extension of the IPT concept to redesign the contracting process. In contrast to the traditional, baseline or "as-is" process that has historically been employed for the procurement of major weapon systems, in which separate government and contractor/offeror organizations serially execute the contracting tasks through the exchange of formal documentation, the alpha contracting innovation involves considerable joint work to collaboratively accomplish the whole spectrum of procurement activities, extending from SOW creation through proposal development to contract definitization. Some benefits of this innovation include reduced cost and cycle time, increased quality and program understanding, improved working relations and cooperation between the government and its contractors, and organizational learning that improves the capability of both government and contractors to effectively employ alpha contracting for future procurement cycles.
The JSOW is widely regarded as a well-managed ACAT I weapon system program, and the ability of its program management team to effectively develop, test and produce this highly-effective, software-intensive and affordable family of missiles makes this program a good exemplar for an instructional case study such as this. The JSOW success to date at alpha contracting leads one to infer that a correlation (if not a causation) exists between some of the key factors identified in the tables above and the contextual factors that are likely to be present on any major weapon system program. Thus, many of the effective JSOW approaches, technologies and decisions offer good potential for employment across a wide range of diverse weapon and information systems, if not directly then at least as a starting point and benchmarking reference for departure. Moreover, by integrating the dozen JSOW factors deemed to be most important into our preliminary alpha contracting decision model, we hope to provide a framework and method that can be useful to PMs and KOs who are interested in employing this approach to other programs.
As noted above, however, this research involves the
investigation of only a single case/data point and the aforementioned
decision model is admittedly very rough and speculative. An agenda
for related future research would involve both longitudinal and
cross-sectional investigation. Specifically, longitudinal work
can be accomplished to observe and trace the JSOW program and
its employment of alpha contracting over time to identify and
formalize the key temporal patterns, triggers and sequencing that
are important in a decision model such as ours; in complementary
fashion, cross-sectional work can be accomplished to observe and
compare other programs and their employment of alpha contracting
to identify and formalize the key contextual factors and managerial
decisions that lead to success as well as failure. Given the status
of the model as it exists here, nonetheless, students today may
benefit by asking, and instructors may benefit from using class
discussion to answer, the following questions pertaining to this
case.
DISCUSSION QUESTIONS
REFERENCES
Arnavas, D. and Ruberry, W. Government Contract
Guidebook Second Edition. Washington, DC: Federal Publications
(1994).
ARQ. Lamm, D., Nissen, M. and Snider, K. (Eds.),
Acquisition Review Quarterly Special Issue on Managing
Radical Change. Forthcoming in 1998.
CTEX. Change Through Ex-Change Innovations - Alpha
Contracting (March 1997), pp. 65-78.
Drewes, R. Early CAS Teaming for Acquisition Success.
Defense Logistics Agency Guidebook, DCMC, Ft. Belvoir, VA (1996).
DSMC. Intermediate Software Acquisition Management
Course (ISAM), Defense Systems Management College, Ft. Belvoir,
VA (1996).
Guenther, O. "Department of the Army Joint Service
Software Perspective," CrossTalk 9:7 (July 1996).
Hearn, E. Federal Acquisition and Contract Management.
Los Altos, CA: Hearn Associates (1996).
JSOW. Personal interviews with the following: PMA-201-
CAPT Bert Johnston, CAPT John Scheffler, LCDR Randy Mahr, Ms.
Pat Hansley; NAWCWD - Dr. Lloyd Smith, Mr. Tom Lamb, Ms. Leanna
Claunch; Eglin AFB - LTC Steve Whitten, Ms. Annette Seda, Mr.
Lane Clark; OC, Inc. - Ms. Cheryl Francis; many other short interviews,
interactions and opportunities for direct observation with government
personnel and contractor employees alike (July-September 1997).
JSOW Site. JSOW Program Web Site; access to this
site is restricted.
Ludwig, R. "The Role of Technology in Modern
Warfare," Software Technology Conference Briefing
(April 1992).
Meyer, T. "Alpha Contracting: Applying the IPT
Approach to Contract Negotiations," Army RD&A
(Jan-Feb 1997).
NARO. "Navy Success Stories: Joint Standoff
Weapon (JSOW) Program," World Wide Web reference: http://www.acq-ref.navy.mil/jsow.html
(1997).
Nissen, M. Knowledge-Based Organizational Process
Redesign: Using Process Flow Measures to Transform Procurement.
Doctoral dissertation, University of Southern California School
of Business Administration (1996).
Nissen, M. "Reengineering the RFP Process through
Knowledge-Based Systems," Acquisition Review Quarterly
(Winter 1997).
Powell, C. "Information-Age Warriors,"
Byte (July 1992).
Rummler, G. and Brache, A. Improving Performance:
How to Manage the White Space on the Organization Chart. San
Francisco, CA: Jossey-Bass (1991).
STSC. Guidelines for Successful Acquisition and
Management of Software-Intensive Systems: Weapon Systems, Command
and Control Systems, Management Information Systems. Hill
AFB, UT: Software Technology Support Center (June 1996).
TACOM. Telephone interview with Ms. Connie Tucker,
TACOM Contracts (August 1997).
APPENDIX
The following documents are available in paper copy only.