To print a PDF copy of this article, click here.
The Fast, Inexpensive, Simple, and Tiny (FIST) framework proposes a broad set of organizational values, but provides limited guidance on practical implementation. Implementing FIST principles requires clarifying the definitions of “fast,” “inexpensive,” and “simple,” recognizing where FIST does and does not apply. Additionally, a subset of the FIST heuristics was expanded upon to increase their usefulness for practitioners. The primary research findings are that FIST principles are less conducive for highly complex or novel systems, immature technologies, future needs, acquisitions in early development phases, or when performance is the foremost value. FIST principles were also found to be constrained by the acquisition process, the requirements process, and oversight.
The Fast, Inexpensive, Simple, and Tiny (FIST) articles first appeared in the Defense Acquisition University (DAU)’s Program Manager, a periodical later renamed Defense AT&L in January 2004 (Ward, Quaid, & Mounce, 2008). The articles were evaluated, iterated, and compiled into a cohesive thesis by Air Force Lt Col Dan Ward (2009) in “The Effect of Values on System Development Project Outcomes.” To this day, Ward’s theories and adept writing style have stimulated significant debate in the Department of Defense (DoD) acquisition community and academia. The FIST framework proposes a broad set of organizational values, but provides limited guidance on practical implementation. Implementing FIST principles requires clarifying the definitions of “fast,” “inexpensive,” and “simple,” recognizing where FIST does and does not apply, and offering additional FIST heuristics based on the recommendations provided herein, to increase their usefulness for practitioners.
The purpose of this article is neither to discredit nor to aggrandize FIST. The intent is to impartially evaluate FIST concepts to increase knowledge and understanding.
Ward mentions in his various writings, the “tiny” aspect is an “inescapable outcome” of accomplishing the first three (Ward & Quaid, 2006a, p. 31); therefore, the focus will be on the fast, inexpensive, and simple tenets of the FIST framework. These tenets should also be thought of as a single idea rather than a value set having separate parts. As a single entity, “an attempt to remove some portion of this value set is likely to impact the program manager’s ability to implement any of it at all” (Ward, 2009, p. 8). Therefore, all the FIST principles must be present for a program to succeed. For example, the Bazooka is a success story because the program (and product) was simple and inexpensive and fast (therefore tiny as well). It adhered to all of the FIST principles.
One principle to delivering systems quickly is to get early and iterative feedback from users (Hebert, 2011). The assertion that early feedback from users leads to rapid development and shorter timeframes is accurate (Ward, 2004), but the limitations should also be discussed. Is it possible to get early user feedback on a Naval carrier? What about early operator feedback on a satellite program? This is nearly impossible unless a satellite or prototype is launched solely for this reason, which is often cost-prohibitive. Historically, around 80 percent of a space system’s life-cycle cost is consumed prior to operations (Hebert, 2011). Therefore, operator feedback is often delayed until the system is fielded because launching a satellite solely for testing and user feedback is cost-prohibitive. To be fair, operator prototypes and simulators obtain a degree of operator feedback. This reduces the risk, but rarely is actual operator feedback with operational assets obtained in the space domain.
The “fast” aspect of the FIST framework also has a fair amount of overlap with rapid acquisitions. Rapid acquisition requires stable requirements (Ford, Colburn, & Morris, 2012). As requirements are usually not fully stable prior to Milestone B for major programs, FIST must be scoped to a certain phase in the acquisition system. The earliest phase for FIST implementation would likely be the Engineering and Manufacturing Development phase (post-Milestone B approval), because a Capability Development Document will be complete with all technologies at a Technology Readiness Level of 6 or greater.
For these reasons, FIST is less conducive in the early phases (pre-Milestone B) of the acquisition process, and therefore is less beneficial for delivering future needs. FIST is also less conducive for complex, large programs in which early operator feedback is not feasible.
Ward suggests several times that large budgets hinder communication with the user community (Ward, 2004). Real feedback from users is extremely important, as Ward would agree, but no evidence is offered as to why this cannot be done with high-dollar programs. One theory is that high-dollar programs are generally for the complex, highly integrated, and interrelated systems. These systems tend to have a variety of users and stakeholders whose exact roles can be vague or undefined. For example, who is the user of an F-22? If the sole answer is the pilot, we are limiting our decisions to one of many users. A “user” with real combat feedback beneficial to acquirers includes air liaison officers, aircraft maintainers, air traffic controllers, instructor pilots, and the training schools, to name a few. Whenever these users have conflicting feedback and desires for the system, the program office must make engineering trade-off decisions. If users have conflicting desires, a subset of users will inevitably be unsatisfied and may view the program office as unresponsive if their desires were not met.
Therefore, large budgets are not the root cause of communication issues with users. Large budgets usually accompany complex, major weapons systems, which have various users and stakeholders with differing values. Consequently, FIST is less conducive for systems in which many users and stakeholders exist.
Figure 1 is the graphical representation of Ward’s Simplicity Cycle. The graph depicts a certain turning point (shown by a “2” on the graph) in which adding complexity decreases “goodness” (ability of a system to do what it’s supposed to do).
Figure 1. The Simplicity Cycle (Ward, 2005)
Understandably, at a certain turning point, adding complexity to a system actually decreases its “goodness.” However, how do we know where this turning point is? Program managers and engineers do not add unnecessary complexity to systems without reason. “An inadequate appreciation for simplicity can result in an overvalued perspective of complexity, which can cause programmatic disaster” (Ward, 2005, p. 20). The opposite is also true, which causes another set of conflicting values. Holding to simplicity because the genius behind the complexity is not understood can also cause programmatic disaster. This concept is better understood with an example.
Holding to simplicity because the genius behind the complexity is not understood can also cause programmatic disaster.
Consider a team meeting to decide if solar retroreflectors are required on the exterior of a space plane. The viewpoint of the chief engineer is that they add complexity, cost too much, and will extend the program schedule. The materials expert contends that the retroreflectors are required because the sun’s rays will burn the exterior before the payload will reach the proper orbit. Which to choose? One cannot blindly say that the retroreflectors go against all four FIST principles and, therefore, should not be pursued. FIST principles must be tempered with mission assurance.
As a result, the FIST principle of “simple” is less conducive for programs and technologies that are complicated and not well understood. One way to utilize FIST principles in immature or uncertain programmatic environments is to budget and plan for a simple, fast prototype. By doing this, much of the uncertainty and technical risk is reduced, removing these barriers to successful FIST implementation. The majority of uncertainty occurs in the early acquisition phases, so once again FIST is less applicable in the early phases of an acquisition. As Mathiassen and Munk-Madsen (1986, p. 20) state, “… in reality the [product development] situation is rarely well defined from the start.”
One way to utilize FIST principles in immature or uncertain programmatic environments is to budget and plan for a simple, fast prototype.
Will a FIST Program Meet DoD Technical Guidance?
Current DoD technical regulations and guidance do not support FIST principles. This can be easily seen for programs that must comply with current DoD technical direction, such as the DoD Net-Centric Services Strategy or the Net Ready Key Performance Parameter (NR KPP) from Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212. The Net-Centric Services Strategy from 2007 promotes integrated systems employing net-centric principles, service-oriented architectures, and global information grid-compliant systems. This strategy ensures warfighters receive the right information at the right level of detail, from trusted and accurate sources, when and where it is needed (DoD, 2007). The NR KPP makes net-centric operations a KPP for all applicable systems (Chairman of the Joint Chiefs of Staff, 2012). These collaborative requirements are program-dependent, meaning they rely on other programs to comply with interface specifications before they can be compliant. Anything taking control away from the program manager goes against FIST because if PMs are dependent on external stakeholders, they will be less able to ensure speed and cost. Additionally, a graduate systems engineering certificate capstone project by Wong and Thompson (2006) cites the numerous cost and complexity issues related to technical interface management. Therefore, requirements mandated as part of the NR KPP are a current barrier to FIST implementation.
Of course the goal is to be compliant as fast and simply as possible, but complying with the NR KPP is neither a fast nor simple process. Once interoperability and net-centricity become better understood and operationalized, fast and simple concepts should be pursued to optimize performance in these areas. Therefore, if the system must comply with complex, undefined requirements (not all systems do), it will be more difficult to implement the FIST methodology. The point here is that Ward is absolutely correct that simplicity has many tangible benefits, but the thick waters of complexity must be waded through first, which many programs and technologies are still in the process of doing (most often in the complex, long-standing programs).
In summary, implementation of FIST principles is limited by DoD technical guidance. When guidance mandates compliance with technically complex requirements, achieving FIST principles is very difficult.
FIST is for Evolutionary (Not Revolutionary) Innovations
Ward states that “small teams + thin budgets + short timelines = significant innovation and combat effectiveness” (Ward, 2004, p. 34). This statement is true for today’s fight; however, is it less applicable if the focus is on winning tomorrow’s war? If the military simply has small teams with thin budgets delivering products and services quickly, we will lose the innovative edge with respect to our novel, complex systems. Some complexity is required, as the Simplicity Cycle states, before simplicity can be achieved.
Books on innovation and Lean principles describe the different strategies of “Invest in Evolution” versus “Invest in Revolution.” Figure 2 maps common verbiage for similar concepts. The incremental improvement strategy is very similar to the FIST strategy. Both require a steady industrial base, mature technology, and the existence of a capability or performance gap in the current system. The risk to this strategy is that key new opportunities (radical innovations) go unexplored for incremental or evolutionary upgrades (Murman, 2002). Although incremental innovations sustain current capability, they don’t produce the radical innovation necessary to address an asymmetric threat. This strategy does have value by delivering newer versions of existing systems faster. The DoD must be careful not to perpetuate existing monuments (in Lean speak), or not to let core capabilities become core rigidities.1
Figure 2. Common Lexicon for Evolutionary and Revolutionary Strategies
|Invest in Evolution||Lean Enterprise Value||Murman et al.||2002|
|= Directional ideas||The Medici Effect||Frans Johannson||2006|
|= Incremental innovation||Making Innovation Work||Davila et al||2005|
|= Sustaining innovation||The Innovators DNA||Dyer et al||2011|
|Invest in Revolution||Lean Enterprise Value||Murman et al||2002|
|= Intersectional ideas||The Medici Effect||Frans Johannson||2006|
|= Breakthrough innovation||Making Innovation Work||Davila et al||2005|
|= Dispruptive innovation||The Innovators DNA||Dyer et al||2011|
|= Radical innovation||Making Innovation Work||Davila et al||2005|
The opposite of an Invest in Evolution strategy is an Invest in Revolution strategy. The Invest in Revolution strategy involves game-changing innovations that result in current systems and technologies becoming obsolete. When a revolutionary innovation emerges, no further evolutionary upgrades are value-added. For example, the advent of electricity made upgrading candles (for practical lighting) obsolete. The advent of low-profile, stealth-like characteristics made many surface-to-air defenses obsolete. The downside of an Invest in Revolution strategy includes costliness, no guarantee a new capability will be fielded, and the risk of a gap in current capabilities (Murman, 2002). However, this is the primary strategy to take advantage of breakthrough technologies to remain a step ahead of the competition (Dyer, Gregersen, & Christensen, 2011). This is not trivial when the nation’s defense is at stake. Herein lies the heart of a major barrier to successful implementation of FIST principles.
First, incremental improvements are normally completed faster, with less complexity (more simplicity) and at lower costs (Dyer, Gregersen, & Christensen, 2011; Johannson, 2006; Davila, Epstein, & Shelton, 2006). Radical innovations are characterized by their novelty, technical immaturity, and mission uncertainty—all contrary to the FIST framework. Therefore, the FIST methodology closely aligns to incremental, vice disruptive, innovation. FIST success stories may not seem incremental based on the extent of the improvements. However, based on the fact that existing, mature technologies were used and the original platforms still have value, the improvements are, by definition, incremental. Although FIST principles have before and can continue to field radical innovations, these results are the exception. As Maier and Rechtin (2009, p. 405) state, “proven” and “state-of-the-art” are mutually exclusive properties.
Additionally, FIST enhances project stability (Ward, 2009). A corresponding limitation to project stability is the reduction of radical innovations. Radical innovation does not come from stable, secure, assured delivery environments. Rather, these game-changing innovations are born from organizations that embrace failure, are not risk-averse, and have a degree of instability as novel ideas are investigated.
When guidance mandates compliance with technically complex requirements, achieving FIST principles is very difficult.
Lastly, Ward agrees that a key to FIST implementation is the use of mature technologies (Ward, 2009), which is often the antithesis of innovation. A FIST program, as with a rapid acquisition program, does not have time to struggle with immature technologies. Unfortunately, many new weapon systems, especially space systems, are relying on immature and complex technologies (Government Accountability Office, 2006). This creates a barrier that must be overcome when trying to implement the fast and simple aspects of FIST.
For these reasons, FIST principles reduce radical innovations. Additionally, FIST principles are not conducive for immature technologies (as Ward would agree, citing mature technology as a key to FIST implementation).
Adding Realism to FIST
FIST is a set of guidelines, or heuristics, to help steer program managers to better decisions. However, many of the core aspects FIST urges program managers to embrace are simply out of the program manager’s control. In these cases, research highlighting the lack of control and authority program managers have, especially in a Major Defense Acquisition Program (MDAP), in the current acquisition system is cited. A realistic set of guidelines for FIST must help program managers decide between available alternatives, not areas that are outside their control. One opportunity in which program managers can make engineering and programmatic trade-offs favoring FIST principles is early in a program, before the requirements, technologies, acquisition category level, and other decisions have been made more permanent. However, when program managers inherit programs later in development, many times implementation of FIST principles is out of their control.
In terms of simplicity, a program manager is given a set of requirements validated by the Air Force Requirements Oversight Council and Joint Requirements Oversight Council, as required. Although a degree of requirements tailoring can be achieved through discussions between the acquirers and users, by and large the requirements have been vetted when the acquiring organization receives them. The requirements for complex, novel systems will consequently force the program office into complexity rather than simplicity.
Whenever and wherever possible, simplicity is an extremely valid heuristic to help manage
In addition, the approval process and program oversight have been shown to be overly complex, very costly, and—to a large degree—outside the control of the program manager (Assessment Panel, 2006; Neal, 2004; Knue, 1991). Therefore, in the reality of complex, novel systems, not only does the required performance force complexity, but the acquisition process forces complexity as well. This is a barrier to implementing the FIST methodology, but should not be confused with the fact that whenever and wherever possible, simplicity is an extremely valid heuristic to help manage a program. Current research investigates the applicability of rapid acquisition methods for traditional development programs with promising initial results. Ford et al. (2012) identify expedited systems engineering and rapid acquisition concepts that can potentially improve processes for traditional programs.
In summary, the requirements process reduces a program manager’s ability to implement FIST principles. The acquisition process and oversight also constrain FIST implementation.
“Fast” and “Inexpensive” Realism
A program manager has a bit more control with respect to cost and schedule variables. Still, the acquisition process can have major effects on these as well, regardless of the program manager’s intent. Ward highlights in “Putting the Pieces Together” that the common saying “better, faster, cheaper: pick two” is short-sighted and unjustifiable (Ward & Quaid, 2006a, p. 32). All program managers should desire better, faster, and cheaper each and every time. The problem lies in the DoD acquisition system, as the military reformers2 found out while fighting tooth-and-nail to overcome it. A good example is the F-16 program as described in The Pentagon Wars (Burton, 1993). The development of the F-16 involved a bitter fight between the military reformers and existing senior leadership. The reformers wanted a cheap, focused air superiority fighter utilizing an existing airframe to reduce costs. At the time, military leadership lobbied for an all-purpose, air superiority aircraft with all the “bells and whistles.” In the end, the F-16 emerged as a very capable, inexpensive, and quickly fielded aircraft (qualities the reformers valued). However, the program continually faced stringent resistance from the acquisition system and leadership. The normal acquisition processes had to be circumvented by nothing short of heroic efforts (Burton, 1993). Therefore, rather than trying to train heroes and ignore the root cause of the problem, the system should set the average program manager up for success. “Pick two” is forced upon program managers, and the following example will highlight how cost and schedule can quickly be taken out of the program manager’s hands.
Program X is an MDAP approaching Milestone B with a cost estimate of $100 million. The Office of the Secretary of Defense Cost Assessment and Program Evaluation (CAPE) staff may disagree with the program office cost estimate when conducting their 80 percent estimate. Therefore, to ensure a successful Milestone, the cost estimate is reconciled and increased to the CAPE’s estimate. Subsequently, the budget approved at Milestone B will reflect this higher cost estimate. In this simplistic yet realistic example, the program office is forced into an increased budget. The same example holds true for schedule as well. A decision authority often regards a condensed schedule as unrealistic, and either increases the cost estimate to accomplish the condensed work, or forces the schedule (using independent schedule analyses, which tend to be more conservative) to expand. The key to passing a Milestone is to have a low-risk, high-confidence program in an executable cost within the budget. In other words, offering a strategy that’s faster and cheaper than comparable programs is often viewed by oversight personnel as the program office staff not fully understanding the scope of the effort or overestimating a learning curve. In this case, the historical acquisition deficiencies work against the program offices’ efforts to streamline and plan in efficiencies. Because of this, a “better, faster, cheaper” program may not receive Milestone approvals as the program is unlikely to be a highly confident, executable program.
The acquisition system limits the strategy to the Iron Triangle concept of cost, schedule, and scope (performance): pick two.
Ward states in his thesis that simultaneously improving cost, schedule, and performance without reducing complexity leads to failure. “Excessive complexity in the organization and the system virtually requires project leaders to improve only two sides of the “Program Manager’s Iron Triangle,” while simple organizations can produce simple technologies that are simultaneously faster, better and cheaper” (Ward, 2009, p. 87). We must temper this statement with the realization of what is acquired from simple organizations producing simple technologies: simple systems. As mentioned earlier, complex, traditional MDAPs do not meet this criteria.
Therefore, the “better, faster, cheaper” strategy is not practical. The acquisition system limits the strategy to the Iron Triangle concept of cost, schedule, and scope (performance): pick two. Additionally, few simple organizations producing simple technologies exist in the complex business of defense acquisition. Program managers must actively manage the trade-offs between cost, schedule, and scope, and be cognizant of how altering one will inevitably alter at least one of the other pillars.
FIST Principles and Performance
Interestingly, the FIST framework does not include performance or quality, at least not in the acronym. Ward states that users must be satisfied with system performance to have value; however, the FIST framework does not foster high performance. In general, a product delivered quickly, cheaply, and simply will not perform as well as one with more time, money, and arguably more complexity. In developing a new iPhone, would a manager rather have 3 months and $100 thousand, or 6 months and $400 thousand? Logically, the performance of the more costly program should be greater. The exception is when acquiring known capabilities, in which acquiring them cheaper and quicker leads to the ability to acquire more, therefore increasing overall performance (think bombs and bullets). However, when discussing performance, requirements must be revisited. If the requirement is such that it can be met using FIST principles, by all means FIST should be adhered to. Defense acquisitions have, at times, lost sight of a requirement’s underlying purpose and delivered gold-plated solutions (solutions with unnecessary functionality and capability). This is very important. If FIST principles allow a program manager to effectively meet a requirement, by all means the FIST methodology should be used.
For known capabilities, FIST principles are valid and should be valued more than gold-plating. For less known capabilities, minimal cost and minimal schedule should not be valued above performance, but effectively controlled and managed. As opposed to acquiring a known capability, “unknown-unknown” risks will surface during development that could not have been predicted. Managing a thin budget with no schedule slack for these unknown-unknowns is not smart management. FIST most certainly reduces unknown-unknown risks if the principles were followed during initial concept development and program initiation. However, applying FIST principles after program initiation would reduce the program’s ability to handle uncertainty.
The FIST principles are not conducive for higher performance systems. Additionally, FIST principles, applied retroactively, limit a program’s ability to mitigate unknown-unknown risks surfacing during development.
In review, Figure 3 compiles the FIST limitations discussed thus far. Now, a logical question would be: Can FIST be applied retroactively to programs already drowning in complexity? Additional research must be done to more thoroughly answer this question; however, it is generally believed that rapid and traditional programs are distinct in their requirements, goals, priorities, speed, and complexity. To this end, a recent Defense Science Board concluded that the Secretary of Defense should formalize a dual acquisition path separating rapid and deliberate acquisitions (Defense Science Board, 2009). In this case, FIST would be much more implementable in the realm of rapid acquisitions due to the limitations listed in Figure 3. Whenever the limitations listed in Figure 3 are not present in an acquisition, or if they can be influenced early during program conception, the FIST principles seem to be highly valuable and effective in meeting warfighter and taxpayer needs.
Figure 3. Fist Limitations
|FIST is less conducive for:|
|FIST is less conducive when:|
|Implementing FIST principles is constrained by:|
FIST as a Set of Heuristics
A heuristic is an aid to learning, discovery, or problem solving by experimental and trial-and-error methods (Heuristic, n.d.). Maier and Rechtin (2009, p. 29) provide a more useful definition in terms of product development, describing heuristics as a problem-solving approach “using guidelines, abstractions, and pragmatics generated by lessons learned from experience.” Heuristics can be considered the “art” side of the “art and science” of project management and/or systems engineering. The human test of a good heuristic is whether an experienced listener knows within seconds that it fits the domain it refers to and cannot be proven false (Maier & Rechtin, 2009). The value of a good set of heuristics, and the practitioner’s ability to know when they are applicable in different situations, should not be undervalued. The acronym for FIST in itself can be considered a set of heuristics:
- Deliver weapon systems as quickly as practical [Fast].
- Deliver at minimal expense [Inexpensive].
- Minimize design and system complexity [Simple].
- Minimize the size of products and processes [Tiny].
Ward concludes his 2009 thesis with a list of FIST heuristics, clearly stating the importance of heuristics. Heuristics are particularly useful in program management because program management is not a hard science, but rather a social discipline (Dyer, Gregersen, & Christensen, 2011). The existing FIST heuristics are generally too broad or contradictory to be useful or actionable. Meaningful heuristics must be actionable to the maximum extent possible (Maier & Rechtin, 2009). For example, heuristic No. 3 from Ward’s thesis is: “The tortoise was faster than the hare.” Heuristic No. 6, however, is the opposite: “The best way to run a program is quickly” (Ward, 2009, p. 102). Opposite heuristics degrade usability. To render a heuristic more usable, the heuristic usually must be de-scoped and more directed to a particular topic. In other words, a heuristic that says, “optimally expending funds is vital to success” is much less useful than the more focused “rarely expend more than 90 percent of current fiscal year funds in the first half of the fiscal year.”
The FIST principles lend themselves well as a set of heuristics because each FIST term is relative. A tiny unmanned aerial vehicle and a tiny tank are not the same size. A complex fighter aircraft and a complex rocket launcher do not have the same complexity. These FIST concepts are, by their nature, relative terms that cannot be bounded for all situations. No checklist exists proving a system to be sufficiently simple, inexpensive, or fast. Therefore, describing FIST through a set of heuristics fits nicely because heuristics are generally agreed upon and cannot be proven false.
In reviewing the multitude of materials related to FIST and in light of the heuristics discussion, the authors offer here a review of the points made thus far as a set of heuristics, with the intent of increasing the set’s usefulness for practitioners. As with all heuristics, we leave it to the community of scholars and practitioners to validate the efficacy of our recommended additions for themselves. Each grouping of heuristics relates to the FIST limitations highlighted in Figure 3 and previously discussed.
The following heuristics relate to the early phases of the acquisition system:
- For the most relevant end product, start early.
- To account for uncertainty, start early (Defense Acquisitions, 2010).
- Without flexible requirements, unconstrained schedule analysis should be completed before accepting a constrained schedule.
The following heuristics relate to complex or novel programs:
- Complexity must first be understood, then minimized (Ward, 2005).
- At a certain program turning point, increased complexity reduces system “goodness” (Ward, 2005).
- Define reliability requirements, then minimize complexity to achieve these requirements (Ward, 2005).
- Minimize complexity until the point when the cost or time required becomes more burdensome than the complexity itself.
The following heuristics relate to innovation and delivering future needs with immature technology:
- Rapid development approaches involve the user much earlier (Ward, 2004).
- Rigorous independent analyses hold much more weight than internal, program office analyses (for cost, schedule, and technical maturity in particular).
- Overfunding leads to tinkering and restrains innovation (Ward, 2004).
The following heuristics relate to tailoring DoD technical guidance and processes to each particular system:
- Tailor processes to specific systems (Blanchard & Fabrycky, 1998).
- Ensure processes are tempered with rationalism (Naur, 1982).
- Don’t let a process force a bad decision (Mathiassen & Munk-Madsen, 1986).
- Don’t let a process hold up a good decision (Mathiassen & Munk-Madsen, 1986).
- Utilizing simple or standard interfaces can help reduce complexity, in turn reducing development costs (Ford et al., 2012).
- Utilize “It Depends” management – maximizing knowledge of the environment and situation at hand optimizes decision-making.
Lastly, the following heuristics relate to the overall DoD acquisition process, including the requirements process and oversight:
- Employ simplicity in both acquisition processes and engineering development.
- Contractors should be allowed to bid their expected schedules without fear of being labeled “nonresponsive” (Ward & Quaid, 2006b).
- Pick three from the beginning, or else be prepared to pick three and get two (see “Adding Realism to FIST” section of this article, discussion on “Fast” and “Inexpensive”).
- The project leader’s influence over the development is inversely proportional to the budget and schedule.
Acquisition professionals should carefully consider the current barriers to successful FIST implementation. Realism was added to several FIST concepts to impartially assess how the framework relates to current practice. Finally, Ward’s heuristics were expanded upon to increase the usability for practitioners. Interestingly, the Air Force announced that its Next Generation Bomber will be managed under the auspices of the Rapid Capabilities Office (Reed, 2012). The outcome of this program will undoubtedly offer a variety of lessons learned. The degree of innovation, either evolutionary or revolutionary, will be of particular interest for the FIST debate.
Once again, the FIST framework is an excellent revival of what the military reformers started: thoughtful inquisition, unyielding drive for excellence, wariness of the trade-offs between complexity and simplicity, and the needs of warfighters over the needs of politicians and programs. However, barriers and limitations exist to successful implementation of FIST in all types of acquisition scenarios.
To print a PDF copy of this article, click here.
Capt Brandon Keller, USAF, is currently the Program Manager, Space Command and Control at the Air Force Research Laboratory Information Directorate. A graduate of the University of Pittsburgh, he also holds an MS from the Air Force Institute of Technology. Capt Keller has served as a program manager in the Global Positioning System Next Generation Operational Control System (GPS OCX) program, a $1 billion software-centric ground control system. Capt Keller’s next assignment was a staff job leading contractor performance assessment processes and various staff briefings for the GPS program director. His research interests include defense acquisition reform and program management oversight.
(E-mail address: firstname.lastname@example.org)
Lt Col J. Robert Wirthlin, USAF, is an assistant professor of Engineering Systems at AFIT. A graduate of the U.S. Air Force Academy, he also holds an MS and PhD from the Massachusetts Institute of Technology. He is a member of the International Council on Systems Engineering, the American Institute of Aeronautics and Astronautics, and the Design Society. His research interests include: acquisition, engineering management, risk, and lean. Previously, he served as a systems engineer and a program manager at Hill AFB, UT; Los Angeles AFB, CA; and Buckley AFB, CO.
(E-mail address: email@example.com)
Assessment Panel of the Defense Acquisition Performance Assessment Project. (2006). Defense acquisition performance assessment report. Washington, DC: Author.
Blanchard, B. S., & Fabrycky, W. J. (1998). Systems engineering and analysis (3rd ed.). Upper Saddle River, NJ: Prentice-Hall.
Burton, J. G. (1993). The Pentagon wars: Reformers challenge the Old Guard. Annapolis, MD: Naval Institute Press.
Chairman of the Joint Chiefs of Staff. (2012). Net-ready key performance parameter (NR KPP) (CJCSI 6212). Washington DC: Author.
Davila, T., Epstein, M. J., & Shelton, R. (2006). Making innovation work. Upper Saddle River, NJ: Wharton School Publishing.
Defense acquisitions: Managing risk to achieve better outcomes. Testimony Before the Subcommittee on Defense, Committee on Appropriations, House of Representatives. (2010). Testimony of Paul Francis, Michael Golden, & William Woods (Report No. GAO-10-374T). Washington, DC: Government Accountability Office.
Defense Science Board. (2009). Fulfillment of urgent operational needs. Report of the
Defense Science Board Task Force. Washington, DC: Office of the Under Secretary of Defense (Acquisition, Technology and Logistics).
Department of Defense. (2007). DoD net-centric services strategy. Washington DC: Chief Information Officer.
Dyer, J., Gregersen, H., & Christensen, C. M. (2011). The innovator’s DNA. Boston: Harvard Business School Press.
Ford, J. S., Colburn, R. M., & Morris, Y. A. (2012). Principles of rapid acquisition and systems engineering [Graduate research project]. Wright-Patterson AFB, OH: Air Force Institute of Technology.
Hebert, B. (2011, August). Appropriations, Congress & budget execution: Color of money 101. Defense Acquisition University presentation to DMSMS and Standardization Conference, Hollywood, FL.
Heuristic. (n.d.). In Merriam-Webster’s online dictionary. Retrieved from http://www.merriam-webster.com/dictionary/heuristic
Johannson, F. (2006). The Medici effect. Boston: Harvard Business School Press.
Knue, T. G. (1991). Oversight of and within the Department of Defense: Is it becoming counterproductive? Unpublished manuscript, Air Force Institute of Technology, Wright-Patterson AFB, OH.
Maier, M., & Rechtin, E. (2009). The art of systems architecting (3rd ed.). Boca Raton, FL: CRC Press.
Mathiassen, L., & Munk-Madsen, A. (1986). Formalizations in systems development. Behaviour and Information Technology, 5(2), 145–155.
Murman, E. (2002). Lean enterprise value: Insights from MIT’s lean advancement initiative. New York: Palgrave Macmillan.
Naur, P. (1982). Formalizations in program development. Behaviour and Information Technology, 22, 437–453.
Neal, M. J. (2004). Establishing a foundation to capture the cost of oversight for a major defense program within the information technology acquisition community. Unpublished manuscript, Air Force Institute of Technology, Wright-Patterson AFB, OH.
Reed, J. (2012, February 24). AFA: New bomber program ‘underway’. Retrieved from DoD Buzz
Online Defense and Acquisition Journal at http://www.dodbuzz.com/2012/02/24/afa-new-bomber-program-underway/
Ward, D. (2004). Doing less with more. Defense AT&L, 33(6), 30–34.
Ward, D. (2005). The simplicity cycle. Defense AT&L, 34(6), 18–21.
Ward, D. B. (2009). The effect of values on system development project outcomes (Thesis No. AFIT/GSE/ENV/09-M08). Wright-Patterson AFB, OH: Air Force Institute of Technology.
Ward, D., & Quaid, C. (2006a). FIST Part 5: Putting the pieces together. Defense AT&L, 35(3), 30–33.
Ward, D., & Quaid, C. (2006b). It’s about time. Defense AT&L, 35(1), 14–17.
Ward, D., Quaid, C., & Mounce, G. (2008). The FIST handbook. Beavercreek, OH: Rogue Press.
Wong, J., & Thompson, R. (2006). Assessment of technical interface management for complex Department of Defense satellite systems. Graduate Systems Engineering Certificate Capstone Project. Wright-Patterson AFB, OH: Air Force Institute of Technology.
- “Core Capabilities and Core Rigidities” is the subject of a seminal paper by Leonard-Barton in her 1992 Core Capabilities and Core Rigidities: A Paradox in Managing New Product Development.
- A group of military and civilian analysts emerging in the 1980s opposed lengthy, high-technology, complex weapon systems.