Photo Credit: https://unsplash.com/@wattsroofingsupplies

I have been meaning to introduce this new term, Minimum Viable Sustainment (MVS), into our acquisition practitioner lexicon for some time now.  Unfortunately, I fell into the age-old, “Meh, it’s sustainment, I’ll get to it later” mentality.  That, my friends, is a mistake – we shouldn’t be considering sustainment as a follow-on activity to an initial acquisition strategy – even when we are working in an urgent/critical need or rapid prototyping environment.

Why is this important jargon we need to bring to the forefront now?  Because the opportunities for rapid prototyping and rapid fielding are increasing – especially in the Department of Defense.  These opportunities can present themselves in the form of Minimum Viable Products (MVPs) and/or prototypes (note: MVPs and prototypes are not necessarily the same). Users are finding new and innovative solutions arriving on their doorsteps, and since these solutions are meeting the operational environment for the first time, it is not unreasonable to predict there is a risk of encountering performance issues – technical and/or employment.

So, imagine you are one of these users working in an austere environment several time zones away from your developer.  A new prototype piece of equipment shows up to your warehouse.  This delivery itself is not a surprise to you, because hopefully you have been part of the team providing inputs on the capability gap and feedback on the prototype’s design/features.  You open the box, remove the hardware, and then reach in for the instruction manual.  The instruction manual…ummm…where is the instruction manual?  No matter, I’ll just call the Help Desk.  The Help Desk…ummm…where is the phone number for the Help Desk?

And back onto the shelf the equipment goes…because, while you are willing to leverage new tech in the operational environment, you are unwilling to do so without the opportunity for some semblance of reach back support.  All the front end accelerated development resulted in a box sitting in a warehouse until there magically appears some minimum level of support.

I actually encountered this situation twice in the government.  The first time, I was deployed and sat next to the Army logistician who was informed a large shipment of tethered sensors were arriving by ship to the region.  The shipment delivery schedule was a surprise to the logistics team, as there was no employment plan in place to forward ship the systems once they arrived in the warehouse – which subsequently resulted in the unused equipment taking up precious space in a limited staging warehouse until an expedited fielding plan could be created and executed.

The second time, I was a program manager for an urgent capability tasked to multiple military services to field.  I received a frantic call from my leadership that the Chief of Staff of the Air Force was asking why the critical systems were sitting in a warehouse down range, unused, and there was no support.  Fortunately, there had been a mix-up, as our team not only shipped the capability, but has also coordinated with the Air Force users what kind of support would accompany the systems.  Some other service (which shall remain unnamed) had not provided a support structure to accompany their similar capability, thus resulting in the warehousing.

Why is this important?

The takeaway is that while it is important to maximize opportunities to accelerate the fielding of innovative solutions to users in order to maintain a competitive advantage, it is equally important to provide a mutually-agreed Minimum Viable Sustainment (MVS) solution to ensure the user has some means of reach back support when employing the capability to reduce the risk of the system sitting on a shelf.

What does an MVS look like?

It depends.  Really.  The critical step is to have a developer/user discussion at the onset of the program activity to come to a mutually-agreed vision for what sufficient level of support would be needed in order for the user to employ the MVP solution (recognizing there are certain limitations to what levels of support can be provided based on cost, schedule, and performance for a rapidly developed prototype).  It could be as simple as a contact number for 24/7 access to the program office team.  It could be larger and include the contact to the developers (OEM contractors).  Familiarity with the MVP is also a consideration – a user may be willing to accept less MVS if they have been involved in the development and testing activities.  This is important to understand early in the acquisition process because the level of MVS could drive contractual language and subsequent costs.

For the Department of Defense, now that the Office of the Secretary of Defense (OSD) has officially released the Adaptive Acquisition Framework (AAF), the program execution teams are encouraged to leverage opportunities to rapidly prototype and release capabilities to the warfighter in shorter cycles.  The key benefit of this methodology is reducing risk of waiting years to introduce the product to the operational environment, to avoid learning a product is no longer relevant to the mission it was originally developed to support, resulting in waste of taxpayer resources. However, this vision only works if the user is willing to employ the capability in the operational environment to enable the feedback loop.  If the user does not have sufficient support and subsequently refuses to employ the capability, then there was no point to delivering it. Additionally, since fielding an MVP or a prototype can contain performance risk, ensuring an MVS is co-delivered provides reassurance with a direct feedback mechanism to the program office and/or the developers and contractors.

Don’t wait until fielding to address the MVS.  Establish a clear understanding between the developers and users early in the acquisition strategy because the MVS solution could impact the cost/colors of money, the contracting strategy, the test strategy, and the fielding strategy.

So remember, when building your MVP, be sure to incorporate the MVS!!!

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