This is number 5 in a 7-part series of articles about sustaining your complex system.
In this article we talk about executing the various programs arising from your risk mitigation plans. Because this is, at its heart, program management, this is the part of your organization that is most like any other program office. But there are still some unique aspects to consider.
“Various programs arising from risk mitigation” includes, for our purposes, anything from a simple technical order tweak to a major program. It includes any change to your complex system.
You already realize that any system modification schedules you set must integrate well into the current weapon system tempo and all the other system modifications on-going or planned. And since “no plan survives contact with the enemy” any plan you created is likely to need tweaking as it gets executed, which means again, integration with all the other schedules. This part of sustainment is also your last ditch stop gap for realizing that one or more of your changes to your system simply won’t work at all with some other changes.
Because of this, the ICBM program had a deployment integration team that had the authority to review and tweak schedules (in concert with management of course) so that the plan didn’t constantly fall apart as reality intruded.
Another important aspect of legacy system modification is production FRACAS.
Repair is executed with the intent of re-creating your complex system to be as good as new. Old parts are replaced. Worn out devices are renewed. Everything is like new.
Only, of course, it is not. Everything is as “good as old” not as “good as new”. Nothing remains quite the same. This is the reason to institute a FRACAS-like system at your repair facilities. Not just to detect early failure modes as an earlier article said, but also to increase the control you have over how your system is being subtly changed.
I have participated in far too many soul-searching meetings with our people in charge of repair, or our people in charge of finding parts, that had the exact same conversation: “But there wasn’t any change to the specification, I mean, not really.” Only to find there, of course, was.
If there is a need to institute a FRACAS-like system at the repair facilities to capture emerging failure mode data and maintain your baseline, it would be very foolish to not institute the same in production during your mods, and for the same reasons.
Being a program management function, you will also be presented with the perennial choice of paying for data now, or leaving your successors with massive headaches. Hopefully, your experiences with being on the receiving end of this as a sustainment manager will help inform your decisions.
In summary, consider empowering a deployment schedule integration team, ensure FRACAS occurs on your production lines, and buy as much data as you can justify.
Next month, we will dive into more details of CLFA. The final article the following month will conclude this series by exploring a few of the aspects of your three Complex System Sustainment Management Model enablers: people, process, and data.
The latest and most widely recognized Guidebook for SSE and PP along with risk assessments is the USAF SSE Cyber Guidebook. In collaboration with industry and other DoD authoritative bodies and offices, this is the workflow resource to use. It’s detailed tasks and processes leads from requirements thru testing.
NIST is not for weapon system as per DNI.
For DoD users, go to AcqNotes for the current version while the latest 3.0 is in staffing to include the AAF.
Times and directives have changed along with SSE, SE and the digital campaign, so use the recognized military source document recognized by NDIA, US Army contracting, Navy and USAF components and offices.
Joe, can you include your organization and / or position so that your comment carries more weight? Thanks!