search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
ARMY AL&T


ATOMS VS. BYTES


Agile hardware program managers consider specialized skills like welding, electrical, engine repair, material repair, tailoring, plumbing and other skill sets when addressing hardware prototypes in “sprint-like” events.


by reprioritizing or inserting desired features based on perfor- mance data or new insights. Design and development for riskier features can continue in an independent iteration while an oper- ationally viable iteration goes into a fielding phase. Additionally, iteration independence enables previous iterations to serve as a fallback plan should risky performance features fail to meet user needs. By using iteration independence, the program manager can deliver operationally relevant capabilities while developing riskier features or modules in future iterations.


termination. It is important to note that decision-makers could determine a “go” decision even if the prototype does not meet benchmarks. Te potential of the future iterations to meet risky, yet valuable, benchmarks will also impact the decision.


From the “go” decision, the program will address readiness for fielding as well as the desire for iterative development of another prototype. Production and fielding decisions will require analyses considering performance, production, sustainment and opera- tional risk. Te first system that enables the user to meet mission needs is the minimum viable capability (MVC); it is both an operational and learning tool as described in my 2022 presenta- tion. Te program office will assess the need to develop future prototypes or modular features against the remaining program budget and schedule.


Should the program office determine the need to develop another iteration, it will conduct a prototype design review. Te contrac- tor, program office and the user are the participants as well as other relevant stakeholders. Performance data, emerging require- ments, changes to tactics and the realization of other needs will scope the next prototype iteration. Te team will reevaluate and prioritize desirable features considering cost, schedule, perfor- mance and contracting requirements.


Tis cycle can repeat or end on a case-by-case basis depending on the performance, schedule and funding constraints of the acquisition.


ITERATION INDEPENDENCE Te independence of each prototype iteration reduces risk. Tis independence requires that each iteration undergoes its own independent baseline even if the design is similar to previous iterations. Each independent iteration is evaluated on its own merits. Te team can mitigate the impacts of requirements creep


CONCLUSION Tailoring the Software Acquisition Pathway for hardware capa- bilities is an effective way to get capabilities to the field fast. While the HMDS and the NPC programs demonstrated hard- ware development using minimum viable products for Urgent Capability Acquisitions, programs using Middle Tier of Acquisi- tion or Major Capability Acquisition pathways could also consider this approach. Agile hardware strategies enable program managers to make rapid decisions during design, development and test while addressing requirements creep in real time. Involving the end user throughout development for feedback will help clarify ambigu- ities in requirements definition and improve communications throughout system testing to reduce the impacts performance issues and schedule slips. MVP and agile strategies have the potential to enable hardware programs in any acquisition path- way under the Adaptive Acquisition Framework to develop high performing and worthwhile capabilities at astonishing speeds.


For more information, email the author at joseph.e.novick.civ@ army.mil.


JOSEPH NOVICK is the deputy director for the Advanced Development and Manufacturing Capabilities – Pharmaceutical Infrastructure (ADMC – PI) within the Joint Project Lead for Radiological and Nuclear Defense Enabling Technologies and the Joint Program Executive Office for Chemical, Biological, Radiological and Nuclear Defense. He served as the program manager for the HMDS and the deputy program manager for the NPC. He holds an M.S. in systems engineering management from the Naval Postgraduate School, a B.S. in biochemistry from the University of Virginia and a Certificate of Participation from the Massachusetts Institute of Technology. He is a DAWIA Certified Practitioner in engineering and technical management and Advanced in program management.


https://asc.ar my.mil


101


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74  |  Page 75  |  Page 76  |  Page 77  |  Page 78  |  Page 79  |  Page 80  |  Page 81  |  Page 82  |  Page 83  |  Page 84  |  Page 85  |  Page 86  |  Page 87  |  Page 88  |  Page 89  |  Page 90  |  Page 91  |  Page 92  |  Page 93  |  Page 94  |  Page 95  |  Page 96  |  Page 97  |  Page 98  |  Page 99  |  Page 100  |  Page 101  |  Page 102  |  Page 103  |  Page 104  |  Page 105  |  Page 106  |  Page 107  |  Page 108  |  Page 109  |  Page 110  |  Page 111  |  Page 112  |  Page 113  |  Page 114  |  Page 115  |  Page 116  |  Page 117  |  Page 118  |  Page 119  |  Page 120  |  Page 121  |  Page 122  |  Page 123  |  Page 124