JSOW Alpha Contracting Case Study (Software Version)

Dr. Mark E. Nissen, Naval Postgraduate School

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


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.


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.


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.


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.


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.


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."


Table I Key Process and Contextual Factors

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

FactorEMD/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 YesYes
Contractor openness Yes Yes
Technical IPTs YesYes

* 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 typeAlpha experience
CompetitionTechnical IPTs
PMO commitment
External:(Quadrant IV) (Quadrant III)
Program phaseACAT
Budget/schedule pressure System
Contractor openness Complexity

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

QuadrantFactor Operationalization LRIP Lot 1LRIP Lot 2
QI:Contract typeCost vs. fixed price +1 -1
CompetitionSole-source vs. competitive +1+1
PMO commitmentPM committed vs. ambivalent +1+1
Q2:Alpha experiencePrevious experience (yes vs. no) +1+1
Technical IPTsCurrently employed (yes vs. no) +1+1
SystemMissile vs. other class -1-1
ComplexitySimple vs. complex program -1-1
GeographyCollocated vs. dispersed -1-1
QIV:Program phaseProduction vs EMD +1+1
Budget/Schedule pressure Low vs. high+1-1
Contractor opennessOpen vs. closed +1+1
Total Score: +40


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.


  1. How do the JSOW alpha contracting scores (i.e., from the decision model) compare with scores from other major weapon system programs that have been discussed in class, and what factors appear to account for the most significant differences in terms of contracting success? Why?
  2. Which of the dozen alpha contracting factors from the decision model above appear to be the most useful in terms of predicting future success with the alpha approach, and which appear to offer the least value? Why?
  3. What additional steps would you (as Program Manager) take with respect to the integration of the technical (i.e., weapon system development and production) activities with those associated with the seasonal contracting process? What effect would you expect for such steps to have? Why?
  4. What process changes would be required to effectively adapt the JSOW alpha process for use in: a) a competitive procurement; b) a simplified acquisition; or c) a major automated information system (MAIS)?


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: (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).


The following documents are available in paper copy only.