Hurry!  I need your help!  We (yes, you!), the influencers, innovators, and users of the DoD acquisition ecosystem, need to put the kibosh on this newly-forming, open semantic issue of speed to failure versus speed to learning before the entire workforce descends into an unnecessary debate and creates inflated policies preventing opportunities to speed with discipline.

A superstar Air Force captain recently reminded me, “Deb – words have meaning.”  It was an excellent statement, and appropriate for this situation.  So, let’s take one step back, clarify the “going fast” intent, and use words that have the intended meaning to assist proactive program execution learning and not reactive hindsight failure lessons.

There is evolving discussion between the DoD acquisition functional communities on the concept of going fast to drive towards failure.  First, to be clear, “going fast” means selecting the most appropriate acquisition framework(s) for the specific activity, and subsequently tailoring and trimming the acquisition strategy to enable fielding capability to the warfighter at the speed of relevance.  Second, no one in our ecosystem is advocating failure as the driver for acquisition strategy activities – the intent is to deliver a successful capability.  Nowhere are “S words” popping up – sloppy, short-sighted, solo, etc.

Where I think we have stumbled into failed semantics is that when we say speed to failure, the meaning is to find out as early in the program execution process and at the lowest resource impact level as possible that a particular strategy is not on the right vector to enable the program to meet its cost/schedule/performance target(s).  For example, waiting fifteen years to obtain data proving a system will not support the mission is too costly and too late – the time and resources have been expended.  Sunk costs.  Rather, it is better to establish pivot points and conduct shorter, smaller events (prototypes, tests, Minimum Viable Products, software sprints, etc.) throughout the program execution that enable early data collection at lower costs to enable a strategy pivot.  This is the concept of learning – collecting data, turning it into information, and building into knowledge to make informed decisions. 

A test that does not successfully meet performance parameters, a negative MVP feedback from a user, or a poor UX experience in a software release – these can all be seen as “failures” when in actuality, these are key data points that help the program team learn early where deficiencies exist and how to prioritize improvements.  The learning from these activities enables the program stakeholders to pivot during the program development rather than waiting until the end.  Learning is the proactive, forward-looking goal during program execution.  Failure is the reactive, hindsight perspective.

So, hurry – speed IS of the essence here to nip this semantics issue in the bud.  Please spread the word and let’s vector the DoD acquisition ecosystem towards learning to increase likelihood of delivering the right capability to the right user at the right time.  Let’s use the words that mean what we intend.  Acquisition strategies must be developed to maximize learning opportunities to help keep the program vector pointing towards the target.  Establish a learn fast, learn often strategy to enable continual pivot point opportunities to reduce program risk, not a fail fast, fail often strategy that is too costly in both time and resources.  Finally, since we can’t use the Microsoft Word button FIND ALL on the phrase, “Fail fast, fail often” and REPLACE ALL with, “Learn fast, learn often”  across the entire ecosystem, I ask that we all do our part to use the right words and keep forward focused.

Thank you for your help!

Disclaimer:  The opinions expressed here are those of the authors only and do not represent the positions of the MITRE Corporation or its sponsors.